【问题标题】:Nullable foreign keys vs relational tables for N:M relationsN:M 关系的可空外键与关系表
【发布时间】:2011-09-15 12:20:59
【问题描述】:

我是一名存在疑问的数据库设计师。

如果您的 table1 必须与 table2 或(独占或一个或另一个)table3 有关系,

  • 您会选择哪种方法以及为什么要选择高读取性能?

已知可空索引字段(选项 A 表 1)是一个错误的决定(请参阅 O'Reilly 高性能 MySQL 第 3 章或MySQL manual),但也知道执行连接需要时间(选项 B )...

学术选择是 B,但我想要一个真实世界的解释,如果它真的更适合高性能。

提前致谢!!

【问题讨论】:

  • 看不到你的照片。该链接对我无效。

标签: mysql database performance database-design


【解决方案1】:

避免可为空的“外键”。它们有多个缺点。

当外键包含空值时,并不总是强制执行引用行的约束。但是,不同 DBMS 之间的默认行为并不一致。一些 DBMS 支持配置选项来更改可空外键的行为,而有些则不支持。因此,从数据完整性的角度来看,SQL 开发人员和用户可能不清楚可空外键约束的实际含义。在 DBMS 产品之间甚至在使用相同产品的不同服务器之间移植数据库可能会产生不一致的结果。

数据库设计工具、集成工具和其他软件并不总是正确地支持它们,它们产生的结果可能是错误的。

外键经常用在连接和其他查询逻辑中,对于那些认为约束有效但实际上无效的用户来说,问题更加复杂。

从逻辑上讲,可以为空的“外键”约束没有多大逻辑意义。根据 SQL 标准,即使被引用的表是空的,也不会违反这样的约束。这与使用 null 的最常见的所谓理由之一相矛盾——它代表“未知”的情况。如果 X 没有有效值,那么任何“未知”X 肯定不能是有效值 - 但 SQL 将允许它。

没必要。您始终可以构造表,以便不需要空值。因此,为了简单和准确,最好将空值排除在外而不是放入。

【讨论】:

  • 感谢您的回答。但是,我想要的不是理论(我知道关系理论),而是关于确切示例及其在 MySQL DSMS 中如何工作的技术答案。我不知道更改 DBMS 的问题,以及它们如何管理空值。我只对 MySQL 感兴趣,并且对高性能结果更感兴趣,而不是纯粹的理论原因。再次感谢!
  • @Emilio,我的全部答案是关于实际和技术问题。我不知道你为什么会有其他想法。我看不到您的图表,因此无法评论确切的示例。我的答案适用于您可能使用可为空的外键约束的任何地方。
  • 我们看不到您的图表,因为我们没有在 yammer 上注册。
【解决方案2】:

在实践中,适合性能的设计取决于访问数据的“权重”程度。

当部分数据(table2或table3)被频繁访问时,使用“表继承”是合适的。 如果所有数据(无论 table2 或 table3)都被频繁访问,则使用“Nullable FK”是合适的。


然而,“Nullable FK”可以通过基于“表继承”的视图来建立。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-09-10
    • 2011-11-11
    • 1970-01-01
    • 2019-03-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多