什么时候参照完整性不合适?

什么时候参照完整性不合适?

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

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

有时,您更关心的是捕获数据而不是数据质量。假设您正在聚合来自不同系统的大量数据,这些系统本身就存在数据质量问题。有时,您追求的是更高的数据质量,将所有东西都放在一个地方,即使有损坏的键等,这代表着向真正的数据质量迈进的起点。这并不理想,但它确实发生了,因为Beenfits可能会超过权衡。

通常,这应该是模式结构设计决策还是接口设计决策?(或者可能两者都不是)

关于系统开发的一切都围绕着信息安全展开,其中的一个关键要素就是数据完整性。数据库结构在可能的情况下应该倾向于强制执行这些内容,但是您通常不处理现代数据库系统。有时,您的数据源是一个古老的学校AS400,带有陈旧的应用程序。有时,您必须构建一个数据和业务层,以提供数据完整性。

只是我的想法。

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

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

根据“验证规则”,我指的是“购物车中的商品”等规则。您可能需要验证规则,也可能不需要验证规则。但是我认为主键/外键总是很重要的(或者稍后您可以找到您希望拥有它们的主键/外键)。我认为如果您想在某个时间点进行复制,就需要它们。

1. 什么时候参照完整性不合适?

   有时当你复制很多 大量的记录,或恢复 数据来自某种备份,它是 方便临时关闭 参照的约束条件 完整性。

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

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

3. 通常,这应该是模式结构设计决策还是接口设计决策?(或者可能两者都不是)

   我认为它是一个模式设计 决定。想想最好的方法 在关系中模拟问题 条款。以这种方式使用数据库 是故意的。

如果引用完整性不是以性能、可伸缩性和/或其他特性为代价的,那么它总是合适的。

在某些应用程序中,引用完整性可能被用来交换比数据质量更重要的东西。

1. 尽管NoSQL中有几个人,但是多值和OODB领域的感觉却不一样。别听他们的,他们错了。
2. 对。例如,如果车辆唯一标识为(lotid,vin),则lotid是lot表的外键。如果要查找一个批次的所有图片,可以使用车辆图片键(lotid in(lotid,vin))的子集将车辆图片表直接连接到批次表。或者,我不理解你吗?
3. 模式,接口排在第二。如果模式不好,那么拥有一个好的接口不是一个长期的目标。