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

Question

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

我想这会涉及几个子问题:

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

思考？

Answer 1

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

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

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

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

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

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

只是我的想法.

Answer 2

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

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

通过'验证规则',我说的是诸如'购物车中的商品> 0'之类的规则.您可能需要也可能不需要验证规则.但我认为主键/外键总是重要的(或者你以后可以找到你希望你拥有它们).我认为如果你想在某些时候做复制,它们是必需的.