如何解决可空外键与关系表的关系为N：M
|| 我是一个存在疑问的数据库设计师。 如果您有一个table1必须与table2或（排他或另一个）相关联， 哪种方法，为什么要选择高读取性能？ 众所周知，可为空的索引字段（选项A table1）是一个错误的决定（请参见O'Reilly高性能MysqL第3章或MysqL手册），但众所周知联接需要花费一些时间来执行（选项B）。 。 学术上的选择将是B，但是我想对现实世界进行解释，如果它真的对更高的性能更好。 提前致谢！！解决方法
避免使用可为空的“外键”。它们具有多个缺点。
当外键包含null时，对引用行的约束并不总是强制执行。但是，默认行为在不同的DBMS之间不一致。一些DBMS支持配置选项来更改可为空的外键的行为，而某些则不。因此，从数据完整性的角度来看，SQL开发人员和用户可能不清楚可为空的外键约束的实际含义。在DBMS产品之间甚至使用同一产品的不同服务器之间移植数据库可能会导致不一致的结果。
数据库设计工具，集成工具和其他软件并不总是正确地支持它们，它们产生的结果可能是错误的。
外键经常在联接和其他查询逻辑中使用，对于认为约束无效的用户来说，问题更加复杂。
用逻辑术语来说，可为空的“外键”约束在逻辑上没有多大意义。根据SQL标准，即使引用的表为空，也不会违反这种约束。这与使用null的最常见的称谓理由相矛盾-它代表“未知”情况。如果没有X的有效值，则任何\“ unknown \” X肯定不会是有效值-但是SQL会允许它。
没必要。您始终可以构造表，以便不需要null。因此，出于简单性和准确性的考虑，最好将空值留空而不是放空值。
, 实际上，性能的合适设计取决于如何“权重”访问数据。
当频繁访问部分数据（表2或表3）时，使用“表继承”是合适的。
如果经常访问所有数据（无论table2或table3），则使用\“ Nullable FK \”是合适的。
但是，可以通过基于“表继承”的视图来建立“可空FK”。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
