什么时候参考完整性不合适？

Question

我理解需要具有参照完整性以限制条目中的特定值，或者可能在删除请求时阻止它们被删除。但是，我不清楚有效的用例会排除这种机制的使用。

我想这会分成几个子问题：

1. 参考完整性何时不合适？
2. 包含外键列表的多个和/或可能不完整的子集的字段是否合适？
3. 通常，这应该是架构结构设计决策还是界面设计决策？ （或者可能两者都没有）

思想？

Answer 1

参考完整性何时不合适？

如果通常不在数据仓库中使用参照完整性，其中数据是事务数据库的只读副本。另一个不需要RI的例子是当你想记录包含行id的信息时;维护只读日志表的引用完整性是浪费数据库开销。

包含外键列表的多个和/或可能不完整的子集的字段是否合适？

有时您更关心捕获数据而不是数据质量。想象一下，您正在汇集来自不同系统的大量数据，这些数据本身就存在数据质量问题。有时候你会追求更好的数据质量，即使使用破碎键也可以将所有内容放在一个地方等等，这是实现真正数据质量的起点。它并不理想，但确实会发生这种情况，因为这可能会超过权衡。

通常，这应该是架构结构设计决策还是界面设计决策？ （或者可能两者都没有）

关于系统开发的一切都以信息安全为中心，其中一个关键要素是数据完整性。数据库结构应该尽可能地强制执行这些操作，但是您通常不会处理现代数据库系统。有时您的数据源是旧学校AS400，其中包含长期过时的应用程序。有时您必须构建一个提供数据完整性的数据和业务层。

只是我的想法。

Answer 2

我听说过的唯一一个案例是你是否要将大量数据加载到数据库中;在这种情况下，只要您确定数据有效，关闭引用完整性可能是有意义的。加载/迁移完成后，应重新启用参照完整性。

有关于将数据验证规则放在编程代码与数据库中的争论，我认为这取决于软件的用例。如果单个应用程序是数据库的唯一路径，则可以将验证放入程序本身，并且可能没问题。但是，如果几个不同的程序同时使用数据库（例如您的应用程序和您朋友的应用程序），您将需要数据库中的业务规则，以便您的数据始终有效。

通过'验证规则'，我说的是“购物车中的商品”等规则。 0' 。您可能需要也可能不需要验证规则。但我认为主键/外键总是重要的（或者你以后可以找到你希望你拥有它们）。如果你想在某些时候进行复制，我认为它们是必需的。

Answer 3

如果不以性能，可伸缩性和/或其他功能为代价，则参照完整性始终是合适的。

在某些应用程序中，参考完整性可能会以比数据质量更重要的内容进行交易。

Answer 4

1. 参考完整性何时不合适？

   有时候你在复制很多东西 批量记录或恢复记录 来自某种备份的数据，它是 方便暂时关闭 参考的限制 完整性。

2. 包含外键列表的多个和/或可能不完整的子集的字段是否合适？

   以这种方式复制数据 反对的概念 正常化。有 对此有利有弊 方法

3. 通常，这应该是架构结构设计决策还是界面设计决策？ （或者可能两者都没有）

   我认为这是一种架构设计 决策。想想最好的方法 在关系中建模你的问题 条款。以它的方式使用数据库 打算。

Answer 5

1. 从来没有，尽管NoSQL中的一些人，多值和oo-db领域会有不同的感受。不要听他们说，他们错了。
2. 是。例如，如果车辆被唯一地标识为（lotid，vin），那么lotid是批次表的外键。如果你想要找到很多图片你可以通过使用vehicle_pictures键的一个子集（lotid in（lotid，vin））将vehicle_pictures表加入到lot表中。或者，我不理解你？
3. 架构，界面排在第二位。如果架构不好，那么拥有一个漂亮的界面并不是一个长期目标。