database - 没有关系的ERD

Question

我从学校毕业就没接触过数据库，问题太入门还请见谅。

因为我记得如何用 UML 绘制 ERD，最近，我的老板让我用前端为库存系统创建一个数据库。我用谷歌搜索了一些类似的系统，发现在后端，他们的数据库在表之间没有任何关系(我做了 DB reversed UML)。

所以我考虑了一下，即使没有关系(没有外键)，应用程序似乎也能正常工作，那么我们有理由仍然需要表之间的关系有什么意义呢？

Answer 1

这是 CS 类(class)中教授的理论与实际发生的情况之间经常存在明显差异的领域之一。

您经常会遇到的是两者的混搭:显示所有正确关系和键的 ERD 模型，以及数据库中实际实现的“现实”。

正如您所见，实现方面可能是让人大吃一惊的部分:没有定义任何关系，外键只是由不同表中匹配的列名隐含。这是一个权衡。

一方面，管理数据库中的外键会产生开销。每次添加或修改一行时，数据库都需要检查这些外键并确保更改将保持关系完整性。毕竟，这就是您在定义这些关系时所要求的，对吗？在一个开销可以忽略不计的理想世界中，这可能是一件好事，因为作为 DBA，我们喜欢当我们的物理实现与我们花费所有时间创建的理想化模型相匹配时。知道 customer 表中的每个条目都引用 company_location 表中的有效位置，我们睡得更好。

另一方面，还有现实。这种开销不是我们可以轻易忽略的。不是当每晚的批处理负载延迟 4 小时时，并且某些营销经理每 10 分钟询问一次他的数据何时可用的估计。所以我们偷工减料，做出一些妥协。嘿，我们是很好的程序员，对吧？当然，我们可以以一种始终保持数据库引用完整性的方式对应用程序进行编码，而不必花费所有额外的时间来处理数据库中的外键……嗯，也许…​​…事实是真的很难确定 RI 将始终由已经实现了一些潜在复杂业务逻辑的应用程序保留。

当然，使用显式 RI 还有很多其他原因，并且在物理实现中忽略它也有很多充分的理由。你是对的，在一天结束时，应用程序通常在没有定义关系的情况下工作正常。在一天结束时，即使我在开车时不系安全带，我也可能会安全回家。但是，在保证数据完整性方面，在数据库中实现关系是一项非常可靠的保险政策。使用该数据库生成业务洞察力(如一致数据)的分析师。事务应用程序可能依赖于数据在关系上是一致的假设。

¦ 我猜我的意思是这里没有“永远正确”的答案，这确实是个案。我只是建议从假设开始，即您将尽可能忠实地实际实现模型，并使用 RI 完成。然后，如果您发现热点，请根据需要谨慎而保守地放宽这些限制。