我理解需要具有参照完整性，以限制输入时的特定值或可能阻止它们在删除请求时被删除。但是，我不清楚是否有一个有效的用例会将该机制排除在始终使用之外。
我想这将分为几个子问题：
- 什么时候参照完整性不合适？
- 包含多个和/或可能不完整的外键列表子集的字段是否合适？
- 通常，这应该是模式结构设计决策还是界面设计决策？（或者可能两者都没有或两者都有）
想法？
问问题
6891 次
5 回答
19
什么时候参照完整性不合适？
如果通常不用于数据是事务数据库的只读副本的数据仓库，则参照完整性。另一个不需要 RI 的示例是当您想要记录包含行 ID 的信息时；维护只读日志表的参照完整性是对数据库开销的浪费。
包含多个和/或可能不完整的外键列表子集的字段是否合适？
有时您更关心捕获数据而不是数据质量。想象一下，您正在聚合来自不同系统的大量数据，每个系统本身都存在数据质量问题。有时您追求更好的数据质量，即使密钥损坏等也将所有内容集中在一个地方，这代表了迈向真正数据质量的起点。这并不理想，但它确实会发生，因为好处可能超过权衡。
通常，这应该是模式结构设计决策还是界面设计决策？（或者可能两者都没有或两者都有）
系统开发的一切都以信息安全为中心，其中一个关键要素是数据完整性。数据库结构应该尽可能地倾向于执行这些事情，但是您通常不是在处理现代数据库系统。有时，您的数据源是带有陈旧应用程序的老式 AS400。有时您必须构建提供数据完整性的数据和业务层。
只是我的想法。
于 2010-02-02T22:53:07.740 回答
7
我听说的唯一一种情况是，如果您要将大量数据加载到数据库中；在这种情况下，关闭参照完整性可能是有意义的，只要您确定数据是有效的。加载/迁移完成后，应重新打开引用完整性。
关于将数据验证规则放在编程代码与数据库中的争论，我认为这取决于您的软件的用例。如果单个应用程序是数据库的唯一路径，您可以将验证放入程序本身并且可能没问题。但是如果多个不同的程序同时使用数据库（例如您的应用程序和您朋友的应用程序），您将需要数据库中的业务规则，以便您的数据始终有效。
通过“验证规则”，我指的是诸如“购物车中的商品 > 0”之类的规则。您可能需要也可能不需要验证规则。但我认为主键/外键总是很重要（或者你以后会发现你希望拥有它们）。如果您想在某个时候进行复制，我认为它们是必需的。
于 2010-02-02T22:53:22.710 回答
4
如果不以性能、可伸缩性和/或其他特性为代价，那么参照完整性总是合适的。
在某些应用程序中，可以用参照完整性来换取比数据质量更重要的东西。
于 2010-02-02T22:53:40.577 回答
4
什么时候参照完整性不合适？
有时，当您批量复制大量记录或从某种备份恢复数据时，暂时关闭参照完整性的约束会很方便。
包含多个和/或可能不完整的外键列表子集的字段是否合适？
以这种方式复制数据违背了规范化的概念。这种方法有优点也有缺点。
通常，这应该是模式结构设计决策还是界面设计决策？（或者可能两者都没有或两者都有）
我认为这是一个模式设计决定。考虑用关系术语对问题建模的最佳方法。以预期的方式使用数据库。
于 2010-02-02T22:53:50.013 回答
2
- 从来没有，尽管少数人在 NoSQL、多值和 oo-db 领域会有不同的感觉。不要听他们的，他们错了。
- 是的。例如，如果车辆被唯一标识为 (lotid,vin)，则 lotid 是批次表的外键。如果您想查找批次的所有图片，您可以通过使用 vehicle_pictures 键的子集（lotid in (lotid,vin)）将 vehicle_pictures 表直接连接到 lot 表。或者，我不理解你吗？
- 架构，接口其次。如果架构不好，那么拥有一个好的界面就不是一个长期目标。
于 2010-02-02T22:53:13.550 回答