N：M关系可空的外键vs关系表

我是一个存在疑问的数据库设计师。N：M关系可空的外键vs关系表

如果你有一个table1的是必须与表2或（异或，一个或另一个）表3的关系，

它的形式给出，为什么你会选择高读取性能？

是knokn是可空的索引字段（选项A表1）是一个错误的决定（见O'Reilly的高性能MySQL的第3章或MySQL manual），也被称为是一个连接将采取它的时间来执行（选项B）...

书院的选择是B，但我想一个真实世界的解释，如果它是高性能或不是真的好。

在此先感谢！

来源

2011-06-15 Emilio Nicolás

看不到你的照片。该链接不适合我。 – sqlvogel 2011-06-15 13:34:02

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

上引用行的约束时外键包含空并不总是执行。但是，这种默认行为在不同的DBMS之间并不一致。某些DBMS支持配置选项来更改可空的外键的行为，有些则不支持。因此，SQL开发人员和用户可能不清楚可空的外键约束实际上从数据完整性角度意味着什么。在DBMS产品之间或使用相同产品的不同服务器之间移植数据库可能会导致不一致的结果。

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

外键常用于连接和其他查询逻辑，加剧了谁想到约束生效时，它不是用户的问题。

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

这是没有必要的。您始终可以构造表，以便不需要空值。在简单性和准确性的利益，因此最好留出空比把它们。

来源

2011-06-15 13:36:38 sqlvogel

感谢您的回答。但是，我不想要一个理论（我知道关系理论），而是一个关于确切示例的技术性答案，以及它在MySQL DSMS中的工作原理。我不知道更改DBMS的问题，以及他们如何管理空值。我只对MySQL感兴趣，并且比纯粹理论上的理由更关心高性能结果。再次感谢！ – 2011-06-15 16:07:21

感谢您的回答。 – 2011-06-15 16:07:24

@Emilio，我的整个答案是关于实际和技术问题。我不知道你为什么会这么想。我看不到你的图表，所以我不能评论确切的例子。我的答案适用于任何可能使用可空的外键约束的地方。 – sqlvogel 2011-06-15 16:23:45

在实践中，性能合适的设计取决于如何“减肥”您的数据访问。

使用“表继承”时的数据的部分（表2或表3）被频繁访问是合适的。如果所有数据（无论表2或表3）是否被频繁访问，则使用“Nullable FK”是合适的。

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

来源

2011-06-22 03:23:31

N：M关系可空的外键vs关系表

回答

相关问题