数据库设计:一门艺术或难题(管理关系)

Question

我在过去的经验中看到，大多数人在表中不使用物理关系，他们试图记住它们，只通过编码来应用它们。

这里的“物理关系”指的是主键、外键、检查约束等。

在设计数据库时，人们试图在纸上规范数据库，并将数据记录在案。比如，如果我必须为一家营销公司创建一个数据库，我会尝试理解它的需求。例如，哪些字段是强制性的，哪些字段只包含(a或b或c)等等。

当所有的事情都很清楚的时候，为什么大多数人都害怕约束呢？

1. 难道他们不想管理事情吗？
2. 他们缺乏知识(我不这么认为)？
3. 他们对未来的问题不自信吗？
4. 真的很难管理所有这些实体吗？

G 215

在你看来原因是什么？

Answer 1

我总是让DBMS同时执行主键和外键约束；我也经常添加check约束。就我而言，这些数据太重要了，不可能存储不准确的数据。

如果您认为数据库是一系列存储的真正逻辑命题，您将看到，如果数据库包含一个错误命题--错误--那么您可以对您想要的任何结论进行辩论。假设一个错误的前提，任何结论都是正确的。

为什么其他人不使用PK和FK约束等呢？

有些人不知道它们的重要性(因此，缺乏知识肯定是一个因素，甚至是一个主要因素)。其他人担心他们会花费太多的性能，忘记了一个必须修复的错误可能会很容易地消耗掉由于DBMS没有为您做检查而节省的所有时间。我认为，如果当前的DBMS不能很好地处理它们，那么现在可能是更改DBMS的时候了。

Answer 2

许多开发人员在实际执行操作之前将检查数据库上面的代码中的约束。有时，这是由用户体验因素驱动的(我们不想向无法保存到数据库的用户提供选择/选项)。在其他情况下，它可能是由与执行语句相关的痛苦驱动的，确定其失败的原因，然后采取纠正措施。大多数人会认为，如果代码预先进行检查，以及其他可能起作用的业务逻辑，那么代码将更易于维护，而不是通过异常处理程序采取纠正措施。(这不一定是一种理想的思维方式，但它是一种普遍的思维方式。)在任何情况下，如果您在发出语句之前进行检查，并且没有特别意识到数据库可能会被应用程序/用户通过您的完整性来访问--强制执行代码--这一事实，那么您可能会得出结论，数据库约束是没有必要的，特别是在它们的使用可能会导致性能下降的情况下。此外，如果您正在检查数据库上面的应用程序代码中的完整性，人们可能会认为在数据库本身中实现逻辑上等效的检查违反了DRY (不要重复自己)。完整性规则的两种表现形式(数据库约束中的完整性规则和数据库上方应用程序代码中的完整性规则)如果不小心管理，原则上可能会变得不同步。

另外，我也不会低估选项2，因为许多开发人员对数据库约束不太了解，太容易了。

Answer 3

不按重要性降序执行关系有几个原因：

1. People-friendly错误处理您的程序应该检查约束并向用户发送一条可理解的消息。出于某些原因，正常人不喜欢"SQL代码-100013 goble规则违反表gook'.
2. Operational灵活性。您不希望您的操作员试图确定您必须在凌晨3点加载您的表的顺序，也不希望您的测试人员拔出他们的头发，因为他们无法将数据库重新设置为其启动的position.
3. Efficiency.。Cheking约束确实使用IO和CPU.
4. Functionality.。这是一种节省细节的廉价方法，以供以后的经济复苏。例如，在联机订单系统中，当用户终止父订单时，您可以将详细项行保留在表中，如果他稍后恢复订单，详细信息就会重新出现，就像奇迹一样--您可以通过删除代码行来获得这一额外功能。(当然，您需要一些家务管理过程，但这是微不足道的！)

！