【问题标题】:ERD without relationships没有关系的 ERD
【发布时间】:2019-09-18 00:18:43
【问题描述】:

我从学校毕业就没有接触过数据库,所以如果我的问题太入门,请见谅。

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

所以我想了想,即使没有关系(没有外键),应用程序似乎也能正常工作,那么我们还有什么理由需要表之间的关系呢?

【问题讨论】:

  • 外键将强制表之间的参照完整性。通常也意味着创建了一个索引,但如果您愿意,您可以通过其他方式做到这一点。但第 1 点是关键。
  • 大约 8 年前我有过完全相同的经历。这在数据仓库领域很常见。好问题。
  • @Z4-tier 这是在数据仓库中完成的,因为通过引入冗余可能会加快查询某些 KPI 的速度。由于仓库中的数据通常来自关系系统(它是一种副本),因此不稳定的风险非常低。
  • @RuudHermans 非常正确,但请记住有两种非规范化:好的和坏的。好的类型是有意创造的,有一个特定的目标(通常是性能)。坏的类型是无意的,当相同的数据从 2 个独立的上游系统登陆时可能会发生。如果这些重复的数据从未得到协调或以其他方式处理,那就是个问题。如果重复数据不一致(例如来自用于管理计划的系统的财务数据,与来自用于准备 SEC 文件的系统的会计数据),情况会更糟。

标签: database sql-server-data-tools erd


【解决方案1】:

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

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

如您所见,实现方面可能是让人们大吃一惊的部分:没有定义任何关系,外键只是通过不同表的匹配列名来暗示。这是一个权衡。

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

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

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

我猜我的意思是,这里没有“永远正确”的答案,这确实是一个个案。我只是建议从假设您将尽可能忠实地物理实现模型(包括 RI)开始。然后,如果您发现热点,请根据需要谨慎而保守地放松这些限制。

【讨论】:

  • 感谢您的详细解释,我尝试了一些虚拟数据(一个表中大约有 50k 个条目,在生产中,有更多条目),通过选择所有要在前端显示的条目,花了一点时间是时候得到结果了,如果它有一些引用其他表的 FK,那可能会慢得多,但是,我希望前端及时检索数据网格,我想在这种情况下,RI 工作应该依赖于应用程序端来完成?
  • @ikel 实现外键应该不会对 SELECT 的性能产生负面影响,因为 FK 对 read 操作没有任何要求。外键可以增加createupdatedelete操作的开销,具体取决于表和表之间的关系使用的 FK 类型。如果您有一个性能不佳的 SELECT 查询,您可以通过向基础表添加适当的索引、运行collect statistics 或许多其他技术来改进它(但删除 RI 无济于事)。
【解决方案2】:

外键负责参照完整性。

再解释一下:通过添加外键,您是在说“此列中的内容也必须在我指向的列中”。这样可以确保您的命名保持一致。

如果您没有这样做,则在添加冗余信息时可能会引入错误。比如误称“詹姆斯”、“詹姆”。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-07-04
    • 1970-01-01
    相关资源
    最近更新 更多