约束为数据库提供了哪些优势?

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

他们提供的是数据完整性。如果有的话,他们会有一个性能成本(至少是很小的一个)。

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

以下内容,假设您首先获得了约束权:

• 您的数据将对约束有效
• 数据库知道您的数据在约束方面是有效的,并且可以在查询或更新数据库时使用它(例如,为视图上的查询删除不必要的联接)。
• 约束记录在数据库的未来用户中。
• 违反约束的行为将尽快被捕获;而不是在以后的一些不相关的过程中失败。

在关系理论中,允许不一致数据的数据库实际上不是关系数据库。外键对于数据的完整性和一致性是保持数据库“关系”的必要条件;也就是说,数据库的逻辑模型总是正确的。

实际上,定义一个外键并让DB引擎处理以确保关系有效通常比较容易。其他选项包括:

• 无保证数据损坏 在某一时刻
• 数据库触发器-哪个 通常会越来越慢 性能
• 应用程序代码-哪个 最终会导致问题 要么你忘了给右边打电话 代码或其他应用程序访问 数据库。

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

但事实上这是错误的。它应该说“正确的数据是一种资产,错误的数据是一种负债”。

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

在某些DBMS(例如Oracle)中,约束实际上可以 改善 一些查询的性能,因为优化程序可以使用约束来获得有关数据结构的知识。有关一些示例,请参见 this Oracle Magazine article .

我想说所有必需的约束必须在数据库中。外键约束可防止不可用的数据。它们不是一个好东西——除非你想要一个无用的数据库,否则它们是一个需求。外键可能会影响删除和更新的性能,但这是正常的。删除(或者告诉应用程序不要删除此人,因为他在系统中有订单),还是删除用户而不是他的数据,这样做更好?缺少外键可能会导致在查询数据时出现意外且通常很严重的问题。例如,成本报告可能依赖于所有具有相关数据的表,因此可能无法显示重要数据,因为一个或多个表没有要联接的数据。

唯一的约束也是任何合适的数据库的需求。如果一个字段或一组字段必须是唯一的,那么在数据库级别定义该字段或字段组失败将导致非常难以修复的数据问题。

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

更简单的应用程序代码

他们提供的一个好处是,您的应用程序代码需要做的错误检查和验证要少得多。对比这两个代码位,再乘以上千个操作,你就会看到一个巨大的胜利。

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

VS

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

当然,忽略约束的人可能不会在代码验证中投入太多精力…- -

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

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

您可能能够在单个应用程序的代码中正确地管理数据完整性(即使您不这样做,至少断开的数据只影响该应用程序),但对于多个应用程序,它会变得多毛(至少是冗余的)。

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

除非它是一个从设计中消失的约束。在这种情况下,肯定会有代码影响,因为有些代码可能是根据存在的已删除约束编写的。

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

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