设置数据库外键的一些最佳做法是什么

在数据库中设置外键约束时，数据库设计人员应该注意什么是一些很好的经验法则和缺陷？设置数据库外键的一些最佳做法是什么

此外，当继承现有数据库并且外键很少时，将外键添加到现有模式上有多困难？

来源

2011-03-31 Genadinik

使用延迟约束，即使你的DBMS支持它们不允许NULL的外键
避免。
考虑添加ON UPDATE CASCADE选项，如果您认为必须同时考虑替代方案（插入然后更新而不是直接更新候选键）。
请注意，添加约束通常比删除约束更困难。添加约束可能更有可能破坏现有代码（某些DML可能无法工作），因此可能需要更多开发和测试时间才能解决。因此，最好在每个开发周期的早些时候添加约束条件，而不是稍后添加约束条件 - 以后可以随时删除它们。

来源

2011-03-31 15:10:51 sqlvogel

为什么在这个世界上，可延迟性很差？ -.5 – 2011-03-31 19:00:11

因为实际上推迟约束意味着约束不被执行。该事务中的任何代码都可能看到数据库处于不一致状态，这首先破坏了应用约束的目的。 – sqlvogel 2011-04-01 08:29:01

这绝对不正确。延迟约束只有在事务提交之前才可以延迟。那时每个约束都会被检查。对于其他每个会话，数据库都是完全一致的。延迟约束的原因是允许在父项之前创建子记录。但是在提交之前，父母必须在那里。 – 2011-04-04 18:28:47

经验法则，如果您关心数据的完整性，请不要在没有外键关系的情况下建立关系数据库。是的，这可以减缓数据插入/更新并删除一些数据。这是一件好事，因为它正在采取措施来保护您的数据。没有数据完整性数据库中所有数据的所有都是不可信的，因此无用。

以后一般不难设置外键（在SQL Server中运行Alter table statment来添加键），这么做的困难是为什么在设计中不添加它们是不专业的原因相。如果您没有FK，那么非常高兴您拥有一些不符合PK/FK关系规则的数据，需要首先清理。

来源

2011-03-31 13:39:30 HLGEM

尽管我同意使用foriegn键是个好习惯，但我不会说没有它们的话你的数据就没用了。在某些情况下不要使用外键有很好的理由，特别是如果您需要稍后清除某些数据而不影响通常包含FK关系的其他数据。业务规则并不总是遵循数据规则。但是，这些情况非常罕见。我只是说，没有FK并不会使你的数据无用，尽管它可能会让你怀疑。 – 2011-03-31 15:22:14

数据不是无用的，但是你不能证明这一点。通过启用约束条件，您可以随时随地说出事实，即完整性不会受到影响。这是强大的。作为奖励，优化器利用约束。实际上，我认为约束和RI会使数据库平均速度更快，而不是相反; – Ronnis 2011-03-31 17:41:20

如果您不知道dat是否正确，则无用。这并不意味着它不会被使用，因此使用错误的数据会导致糟糕的决定。 – HLGEM 2011-03-31 18:24:19

当你继承一个模式，你将不得不限制添加到它。（不只是外键约束。）
在添加约束之前，有人需要修复坏数据。
需要很长时间修复错误数据。（他们有“实”的工作做。）

的第一个数据库的设计工作，我做了作为一个专业的是，以取代现有的数据库为财富500强又小，即使是上世纪80年代。一些行政人员被分配来解决分析和设计过程中发现的数据错误。他们每天可以修复几百个错误。他们并不是一次只想要所有的错误，每天只有几百人。

所以我每天给他们几百个错误。每天六个月。

来源

2011-03-31 14:58:39

我想这是一种更坏的情况。 *经常*你会遇到这样的情况，但并非总是如此。 – 2011-03-31 15:31:27

实际上它确实很烦人，因为它只需要1个错误就无法启用约束并享受可用于某些更复杂查询的真棒优化器转换。 – Ronnis 2011-03-31 17:39:05

我*喜欢*认为这是最坏的情况。但我已经看到它发生太多次了;我认为这是传统转换的平均值。 – 2011-04-01 00:15:29

设置数据库外键的一些最佳做法是什么

回答

相关问题