我是一名数据库设计师，有一个存在主义疑问。
如果您有一个必须与表2或（排他或，一个或另一个）表3有关系的表1，
- 您会选择哪种方法以及为什么可以获得更高的读取性能？
已知可空索引字段（选项A表1）是一个糟糕的决定（请参见O'Reilly High Performance MySQL第3章或MySQL手册），但也已知连接需要时间来执行（选项B）...
学术选择将是B，但我想要一个实际世界的解释，看看它是否真的更适合高性能。
提前感谢！
可空的外键与关系表对于N:M关系
4
- Emilio Nicolás
1
1无法看到你的图片。链接对我无效。 - nvogel
2个回答
5
避免使用可为空的“外键”。它们有多个缺点。
当外键包含一个空值时，对引用行的约束并不总是得到执行。然而，这种默认行为在不同的DBMS之间并不一致。一些DBMS支持配置选项来更改可为空的外键的行为，而有些则不支持。因此，SQL开发人员和用户可能无法从数据完整性的角度理解可为空的外键约束的实际含义。在不同的DBMS产品之间甚至在使用相同产品的不同服务器之间移植数据库可能会产生不一致的结果。
数据库设计工具、集成工具和其他软件并不总是正确地支持它们，它们所产生的结果可能是错误的。
外键经常用于连接和其他查询逻辑，这加剧了那些认为约束已经生效的用户的问题。
从逻辑上讲，可为空的“外键”约束没有多少逻辑意义。根据SQL标准，即使被引用的表为空，也不能违反这样的约束。这与使用空值的最常见的所谓正当理由之一——它代表“未知”情况——相矛盾。如果没有有效的X值，那么任何“未知”的X肯定不能是有效的值——然而SQL将允许它。
这是不必要的。您总是可以构建表，使得不需要空值。因此，在简单和准确性的利益上，最好将空值排除在外而不是加入其中。
当外键包含一个空值时，对引用行的约束并不总是得到执行。然而，这种默认行为在不同的DBMS之间并不一致。一些DBMS支持配置选项来更改可为空的外键的行为，而有些则不支持。因此，SQL开发人员和用户可能无法从数据完整性的角度理解可为空的外键约束的实际含义。在不同的DBMS产品之间甚至在使用相同产品的不同服务器之间移植数据库可能会产生不一致的结果。
数据库设计工具、集成工具和其他软件并不总是正确地支持它们，它们所产生的结果可能是错误的。
外键经常用于连接和其他查询逻辑，这加剧了那些认为约束已经生效的用户的问题。
从逻辑上讲，可为空的“外键”约束没有多少逻辑意义。根据SQL标准，即使被引用的表为空，也不能违反这样的约束。这与使用空值的最常见的所谓正当理由之一——它代表“未知”情况——相矛盾。如果没有有效的X值，那么任何“未知”的X肯定不能是有效的值——然而SQL将允许它。
这是不必要的。您总是可以构建表，使得不需要空值。因此，在简单和准确性的利益上，最好将空值排除在外而不是加入其中。
- nvogel
4
谢谢您的回答。然而，我想要的不是理论性的（我知道关系理论），而是关于MySQL DSMS中确切示例及其工作方式的技术性答案。我不了解更改DBMS时可能出现的问题以及它们如何处理空值。我只对MySQL感兴趣，并且更加关注高性能结果而不是纯理论原因。再次感谢！ - Emilio Nicolás
@Emilio，我的整个回答都是关于实际和技术问题的。我不知道你为什么会有其他想法。我看不到你的图表，所以无法对具体示例进行评论。我的答案适用于任何可能使用可空外键约束的地方。 - nvogel
这里有一个示例图表：https://www.yammer.com/api/v1/file/2170231/ER_options.png?view=overlay - Emilio Nicolás
我们无法看到您的图表，因为我们没有在 Yammer 上注册。 - bancer
0
实际上，性能适合的设计取决于数据被访问的“权重”。
当频繁访问数据（table2或table3）的一部分时，使用“表继承”是合适的。 如果所有数据（无论是table2还是table3）都经常被访问，则使用“可空外键”是合适的。
然而，“可空外键”可以基于“表继承”建立视图。
- Mike Lue
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接