軟/邏輯刪除與否參照完整性與...？

Question

下面是我的數據庫結構的簡化版本（建築概念網站的證明在MVC 2與實體框架4作爲我的ORM）：

[Stores] 
StoreID (PK) 
StoreName 

[Items] 
ItemID (PK) 
ItemName 
Description 
StoreID (FK) 

[ItemSizes] 
SizeID (PK) 
SizeName 
Price 
ItemID (FK) 

[Users] 
UserID (PK) 
UserName 

房屋賣項目，它進來不同尺寸爲。 [Users]代表標準的asp.net會員店。

我想實現用戶能夠「喜歡」和評價特定項目（和大小），所以我最初的衝動是實現了幾個基本的映射表：

[FavouriteSizes] 
UserID (PK) (FK) 
SizeID (PK) (FK) 

[ItemRatings] 
UserID (PK) (FK) 
ItemID (PK) (FK) 
Rating 

但是，如果我強化參照完整性，當店主想要刪除商品，商品尺寸，甚至關閉他/她的整個商店時，我當然會遇到一個問題。

我已經確定的選項是：

• 級聯刪除：主要CON是接下來的時間中，他收藏最多的項目是完全丟失，
• 軟/邏輯刪除用戶登錄：在這種情況下，我回避他們，因爲當我在過去使用它們時，必須將WHERE IsActive添加到每個查詢都會使表連接變得繁瑣。另外我相信（糾正我，如果我錯了），這會增加EF4的一些複雜性，比如Items.Includes("ItemSizes")。
• 不強制參照完整性（僅在[FavouriteSizes].SizeID FK和[ItemRatings].ItemID FK）：我從來沒有實際做過此事。這似乎是「最簡單」的答案，但我不確定它是否會在稍後回來咬我。

由於並非強制執行這些2個外鍵約束似乎是最簡單的選擇，我的實現將是：

1. 添加ItemName到[FavouriteSizes]，並與ItemSize.Item.ItemName填充它，當一個用戶收藏夾的尺寸
2. 如果收藏的物品不再可用，請添加助手以顯示通知（FavouritedSize.Items Is Nothing），以便用戶可以從收藏夾列表中刪除該物品。
3. 確保任何「最高評分項目」類型報告只會拉回仍然存在的項目。

這個實施是否會引發問題？爲什麼我應該去實施軟刪除而不僅僅是不強制引用完整性（除了保存用於報告的歷史數據）之外，是否有足夠強的理由？我是否錯過了一個更適合的選項？

Answer 1

不強制執行參照完整性是一件有風險的事情，除非你絕對和完全確定沒有人但是你的應用程序會在這個表中填充數據（並且你的應用程序當然要經過測試以確保它保留了完整性）

在實際情況中，我發現這種方法存在風險，因爲一旦系統在生產環境中運行，總會有其他應用程序出現，尤其是數據遷移工具/補丁程序/某些在一些緊急情況下直接進行數據操作 - 最終操縱數據並且在沒有約束的情況下，他們將無法確定關係，並可能最終導致數據不正確。

另外，我不知道你是否需要該輸入，但是看着你的方案，我可能會考慮稍微改變

[Stores] 
StoreID (PK) 
StoreName 

[Items] 
ItemID (PK) 
ItemName 
Description 
StoreID (FK) 

[Sizes] 
SizeID (PK) 
SizeName 

[ItemSizes] 
ItemID (PK) 
SizeID (PK) 
Price 

[Users] 
UserID (PK) 
UserName 

注：我有你[ItemSizes]表分成[Sizes]和[ItemSizes]。

通過這種方式，您可以收藏項目，項目或尺寸（正如您當前所做的），甚至是特定尺寸的項目。

[FavouriteSizes] 
UserID (PK) (FK) 
SizeID (PK) (FK) 
IsActive 

[FavouriteItemSizes] 
UserID (PK) (FK) 
ItemID (PK) (FK) 
SizeID (PK) (FK) 
IsActive 

[ItemRatings] 
UserID (PK) (FK) 
ItemID (PK) (FK) 
Rating 
IsActive 

總之，添加IsActive領域，甚至您的收藏和評分表 - 除了你的主表 - 使用WHERE IsActive檢查，使您的收藏夾/評級是軟 - 上取消該項目/商品尺寸的刪除/大小，然後有額外的邏輯顯示您的收藏夾/評級，以表明不存在較早添加的評級/收藏夾給用戶，似乎是更好的選擇。

我沒有特別肯定IsActive檢查如何與EF一起工作 - 沒有使用過EF - 但總的來說，我會說確保檢查始終存在於所有查詢中通過確保檢查特定點 - 作爲審查過程的一部分。通常情況下，它會成爲團隊中的第二天性，並且確保檢查可以忽略不計。