数据库约束 - 保持还是忽略？

Question

当我在大学学习时，他们教我们数据库的基础知识，基础知识和规则， 其中一个最重要的规则是约束（主键，外键），以及如何建立1-m，1-1，m-n关系。

现在，当我转向真实的商业环境时，他们会告诉我：你应该忘记你所教过的一切;没有约束，所有这些关系都是合乎逻辑的，没有主键，没有外键， 你可以通过代码制定约束。

我不知道谁是对的：我在学术生涯中学到了什么，或者在新的现实生活中学到了什么。你觉得怎么样？

Answer 1

如果有人告诉我忽略我的数据库上的密钥和限制，我会立即忽略它们并开展我的业务。

主键，外键和约束是有原因的。使用它们。它们将使您的生活更轻松，您的数据库更容易理解（并且通常更高效）。

Answer 2

我使用数据库的时间越长，我就越欣赏约束。从长远来看，他们为我节省了很多时间。只有受信任的约束才能确保100％的数据有效性。

我写了一章关于约束的使用与确保数据完整性的其他方法，可以免费下载here

Answer 3

如果您认为约束仅仅是关键主键和外键，那么实际上您并没有开始教授很多“基础知识”。

我建议你看看Hugh Darwen的"An Introduction to Relational Database Theory"，可以在网上免费获得。至少你从那个基础上获得了真正的教育。

Answer 4

我认为约束可以帮助您获得干净的数据。性能有时会提高。在某些情况下，性能会受到约束的影响。但是，答案不是消除约束。您有一些称为“非规范化”的东西可以帮助您处理性能问题（前提是您的查询已经过优化）。您总是可以在这种情况下创建非规范化的汇总表。

那些告诉你“忘记所学知识”的人是否也告诉过你他们忘记了他们在驾驶课上学到的交通规则？

Answer 5

当您有用户访问可能损坏您的数据的数据库（即任何用户）时，数据库约束是一个好主意。我倾向于保留外键约束，以确保编辑数据库中的任何人都知道其他表依赖于当前表中的数据。

Answer 6

当然，很少有终极真理，而且许多商业上成功的产品也避免宣称参照完整性（DRI）。

另一方面，如果您关心数据库中的数据，那么几乎没有比通过DRI更好的方法来保护数据的完整性。

如果你把所有内容都放在最顶层的代码上，你就会希望没有人会通过任何其他方式访问数据库。如果他们这样做，将无法阻止数据损坏（孤立行，不一致和不合逻辑的数据）。

Answer 7

你学到的不仅仅是学术上的东西。但是，是的它有点像柏拉图的乌托邦有时。这是您的数据库所处的完美条件，理想的设计。但这种理想的设计并非总是可行。

约束应尽可能接近DB数据。这样想吧。如果您在代码中编写约束并稍后想要迁移到其他语言/平台并在某个约束中出现错误，该怎么办？这将是灾难性的。诸如PK，FK，约束等的东西被广泛使用。它们已经使用了30多年了。所以，它们不是垃圾，但在某些情况下它们只是不易管理。例如，如果您是Google，则不能仅仅依靠关系模型来提供毫秒级的答案。

因此，基于速度和稳定性等要求，我们有时也会复制数据，我们不使用PK，或者我们不建立关系等。但只有当我们寻找特定的 AND 当我们通过这种方式知道我们会失去什么时。

最后，关系模型仍然只是一个模型。这是一种表达事物的方式。一个非常成功的方式，但它不是天赐之物，所以在某些情况下它必须被妥协。

Answer 8

我花了很多时间来修复那些认为约束属于应用程序代码的不称职者所产生的垃圾数据。如果设计的数据库没有这些必需的东西，它将有不良数据。快速检查任何已经运行了几年的系统，你会发现孤立的记录和缺少所需的信息等。

Answer 9

当我在课堂上时，我们使用原始SQL访问表，并且有很多原始SQL或等效的SQL。在这些情况下，约束通常是好的。

但是，有些系统使用数据库作为后端，这些数据库只能由该特定软件系统访问。在这种情况下，软件应该跟踪必要的关系和约束，并且数据库用作冗余检查，不提供良好的反馈并降低性能。

数据库约束是多余的，因为附加系统需要自己维护约束。反馈是违反了某个数据库约束。如果一个程序能够处理这样的反馈，它就能够自己进行检查。性能成本应该是显而易见的。

约束在开发或测试系统上仍然有用，但是当系统投入生产时，如果出现问题，他们可以做的就是崩溃系统，这通常是你不希望发生的事情。这样的大型系统。

Answer 10

主键非常重要。您需要一种唯一ID行的方法。

但是，根据我的经验，如果您在类中正确封装了数据库访问（即，向/从db读取/写入对象），通常不需要约束。是的，如果10种不同语言的50个不同的应用程序使用相同的数据库，我可能会使用它们。但是如果它的一个应用程序或共享源代码库的一套通用应用程序，我宁愿在一个地方所有数据库操作逻辑，以使应用程序更易于维护。存储过程也是如此，但如果您编写用于处理各种数据库的代码，它们还会在数据库系统之间产生额外的可移植性问题。