软/逻辑删除 vs 无引用完整性 vs ...？

Question

下面是我的数据库结构的简化版本（使用 Entity Framework 4 作为我的 ORM 在 MVC 2 中构建概念验证站点）：

[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

但是，如果我强制执行引用完整性，我当然会遇到当店主想要删除商品、商品尺寸，甚至关闭他/她的整个商店时，就会出现问题。

我确定的选项是：

• 级联删除：主要缺点是用户下次登录时，他最喜欢的项目完全丢失
• 软/逻辑删除：我'在这种情况下，我回避它们，因为当我过去使用它们时，必须将 WHERE IsActive 添加到每个查询中，表连接变得很麻烦。另外，我相信（如果我错了，请纠正我）这会增加 EF4 中的一些复杂性，例如 Items.Includes("ItemSizes")。
• 不强制引用完整性（仅在 [FavouriteSizes].SizeID FK 和 [ItemRatings].ItemID FK 上）：我从未真正这样做过这个之前。这似乎是“最简单”的答案，但我不确定它稍后是否会回来咬我。

鉴于不强制执行这两个外键约束似乎是最简单的选择，我的实现是：

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 - 但总的来说，我想说，通过确保检查特定点可以轻松地确保检查始终存在于所有查询中 - 作为审查过程。通常，它成为团队内的第二天性，并且确保检查可以忽略不计的额外努力。