约束为数据库提供了哪些优势？答案

【问题标题】：What advantages do constraints provide to a database?约束为数据库提供了哪些优势？
【发布时间】：2010-11-19 03:58:07
【问题描述】：

我意识到这个问题可能看起来有点“绿色”方面，但是在我遇到了许多“企业”或“商业”数据库之后，我开始问这个问题。约束为数据库提供了哪些优势？我更多地询问外键约束而不是唯一约束。它们提供性能提升，还是仅提供数据完整性？

我对没有外键甚至没有指定主键的关系数据库的数量感到相当惊讶（只是字段的约束不为空或字段的唯一约束）。

想法？

【问题讨论】：

SO上有很多类似的问题，你也应该仔细阅读它们以获得答案。这个不错：stackoverflow.com/questions/18717/…
“性能提升”是指数据库吗？还是您的意思是“支持开发人员不会浪费多年的生命与不良数据作斗争”。这有点模棱两可。
稍微重复一下这个想法：我们不应该将业务逻辑放在数据层中，对吧？那么如何确保 - 比如说 - 每个采购项目都有相应的采购订单，不是业务逻辑？我觉得它属于数据库；我很高兴使用外键，但我想知道数据/业务层的边界。

标签： database relational-database

【解决方案1】：

更简单的应用程序代码

他们提供的一件好事是，您的应用程序代码需要做的错误检查和验证要少得多。对比这两段代码并乘以数千次操作，您可以看到有很大的收获。

get department number for employee  # it's good coz of constraints
do something with department number

对比

get department number for employee
if department number is empty
    ...
else if department number not in list of good department numbers
    ....
else
    do something with department number

当然，忽略约束的人可能不会在代码验证上投入太多精力...... :-/

哦，如果数据约束发生变化，那是数据库配置问题，而不是代码更改问题。

【讨论】：

【解决方案2】：

“哦，如果数据约束发生变化，那是数据库配置问题，而不是代码更改问题。”

除非它是从设计中消失的约束。在这种情况下，肯定会有代码影响，因为可能已经编写了一些代码，这些代码依赖于已移除的约束。

在“放松”或“删除”任何声明的约束时必须始终考虑到这一点。

除此之外，你当然是完全正确的。

【讨论】：

【解决方案3】：

我想说所有必需的约束都必须在数据库中。外键约束防止不可用的数据。拥有它们并不好——除非您想要一个无用的数据库，否则它们是必需的。外键可能会损害删除和更新的性能，但这没关系。是花一点时间进行删除（或告诉应用程序不要删除此人，因为他在系统中有订单）还是删除用户但不删除他的数据？缺少外键可能会导致查询数据时出现意外且通常很严重的问题。例如，成本报告可能取决于所有具有相关数据的表，因此可能无法显示重要数据，因为一个或多个表没有可连接的内容。

唯一约束也是任何体面数据库的要求。如果一个字段或一组字段必须是唯一的，那么无法在数据库级别定义它会产生极难修复的数据问题。

您没有提及其他限制，但您应该提及。任何必须始终应用于表中所有数据的业务规则都应始终通过数据类型（例如不接受 '02\31\2009' 作为有效日期的数据时间数据类型）、约束（例如一个不允许字段的值大于 100）或通过触发器的方法是逻辑非常复杂，无法通过普通约束处理。（如果您不知道自己在做什么，触发器很难编写，因此如果您的逻辑如此复杂，那么您希望团队中有一名数据库专业人员。）顺序很重要。数据类型是第一选择，其次是约束，最后是触发器。

【讨论】：

【解决方案4】：

在某些 DBMS（例如 Oracle）中，约束实际上可以提高某些查询的性能，因为优化器可以使用约束来获取有关数据结构的知识。有关示例，请参阅this Oracle Magazine article。

【讨论】：

【解决方案5】：

以下内容，假设您首先得到了正确的约束：-

您的数据将在约束方面有效
数据库知道您的数据在约束方面是有效的，并且可以在查询或更新数据库时使用它（例如，删除视图查询的不必要连接）
为数据库的未来用户记录约束
将尽快发现违反约束的行为；不在某些后来失败的不相关进程中

【讨论】：

【解决方案6】：

数据是一种资产。很多教科书都这样说。

但实际上是错误的。应该说“正确的数据是资产，错误的数据是负债”。

并且数据库约束为您提供了数据正确性的最佳保证。

【讨论】：

【解决方案7】：

在关系理论中，允许不一致数据的数据库并不是真正的关系数据库。外键是数据完整性和一致性所必需的，以保持数据库“关系”；即数据库的逻辑模型总是正确的。

实际上，定义外键并让数据库引擎处理确保关系有效通常更容易。其他选项是：

没有 - 保证数据损坏在某个时候
DB 触发器 - 通常会越来越慢高性能
应用程序代码 - 其中最终会导致问题要么你忘记打电话给权利代码或其他应用程序访问数据库。

【讨论】：

我要补充一点，如果您不习惯使用触发器，可能很难找到它们，但最重要的是，编写一致性检查非常困难（尽管大多数读者不会相信我） 100% 正确触发。

【解决方案8】：

当您使用共享数据库集成多个应用程序时，完整性约束尤为重要。

您可能能够在单个应用程序的代码中正确管理数据完整性（即使您不这样做，至少损坏的数据只会影响该应用程序），但是对于多个应用程序，它会变得很麻烦（并且至少是多余的)。

【讨论】：

【解决方案9】：

它们提供性能和数据完整性，后者对于任何严肃的系统都至关重要。每次我看到一个没有任何外键的数据库并且所有完整性都是通过触发器完成的（如果有的话）时，我都会感到畏缩。我在外面看到了很多。

【讨论】：

+1 当数据完整性甚至没有在触发器中完成时，我也会感到畏缩——它是在应用程序代码中完成的！
@Bill - 哎哟！是的，我也看到了。
我打败了你们两个：数据完整性由应用程序代码在单独的计划（每 5 分钟）应用程序中完成。当我遇到这个时，我差点辞职。

【解决方案10】：

数据完整性是他们提供的。如果有的话，它们会产生性能成本（至少是很小的成本）。

【讨论】：

它们可以提高查询的性能；所以性能图并不那么简单。

【解决方案11】：

“只是”数据完整性？你这么说好像是小事一样。在所有应用程序中，它都是至关重要的。所以是的，它提供了这一点，而且是一个巨大的好处。

【讨论】：

我意识到这是一个巨大的优势，但这是典型的承认和优势识别。我想知道是否还可以实现性能提升。
我不知道 FK 约束是否提供了性能提升；我建议他们可能会稍微减损，因为例如，如果允许删除，则需要时间来“计算”。但实际上，使用它们时性能并不是考虑因素。这甚至不是一个决定。总是在关系数据库中有外键。
我同意 FK 对数据库来说是必不可少的，我正在尝试提出其他理由来证明现有系统的重新架构是合理的（不幸的是，数据完整性并不总是足以证明这种排序的合理性决策者的事情）。
您需要向他们展示数据完整性对于持续信任系统包含的数据的能力至关重要。如果您不能确定它是“真实的”，那么这些数据就毫无用处。它可能是孤立的，报告会出错，数据位可能会意外地混合和匹配（一些用户获取另一个用户的信息）等等。到处都是可怕的。这不是一个决定。 FK。总是。
+1 表示“这不是一个决定”。有些事情你从不征求许可。你这样做只是因为这是正确的（如正确的）事情。