我意识到这个问题可能看起来有点“绿色”方面,但是在我遇到的“企业”或“商业”数据库的数量之后,我开始问这个问题。约束为数据库提供了哪些优势?我更多地询问外键约束而不是唯一约束。它们提供性能提升,还是仅提供数据完整性?
我对没有外键甚至没有指定主键的关系数据库的数量感到相当惊讶(只是字段上的约束不为空或字段上的唯一约束)。
想法?
我意识到这个问题可能看起来有点“绿色”方面,但是在我遇到的“企业”或“商业”数据库的数量之后,我开始问这个问题。约束为数据库提供了哪些优势?我更多地询问外键约束而不是唯一约束。它们提供性能提升,还是仅提供数据完整性?
我对没有外键甚至没有指定主键的关系数据库的数量感到相当惊讶(只是字段上的约束不为空或字段上的唯一约束)。
想法?
“只是”数据完整性?你这么说好像是小事一样。在所有应用程序中,它都是至关重要的。所以是的,它提供了这一点,这是一个巨大的好处。
数据完整性是他们提供的。如果有的话,它们会产生性能成本(至少是很小的成本)。
它们提供性能和数据完整性,后者对于任何严肃的系统都至关重要。每次我看到一个没有任何外键的数据库并且所有完整性都是通过触发器完成的(如果有的话)时,我都会感到畏缩。我在那里看到了很多。
以下,假设您首先获得了正确的约束:-
在关系理论中,允许不一致数据的数据库并不是真正的关系数据库。外键是数据完整性和一致性所必需的,以保持数据库“关系”;即数据库的逻辑模型总是正确的。
实际上,定义外键并让数据库引擎处理确保关系有效通常更容易。其他选项是:
数据是一种资产。很多教科书都这样说。
但实际上是错误的。应该说“正确的数据是资产,错误的数据是负债”。
并且数据库约束为您提供了数据正确的最佳保证。
更简单的应用程序代码
他们提供的一件好事是您的应用程序代码必须做的错误检查和验证要少得多。对比这两位代码并乘以数千个操作,您会看到有很大的收获。
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
当然,忽略约束的人可能不会在代码验证上投入太多精力...... :-/
哦,如果数据约束发生变化,那是数据库配置问题,而不是代码更改问题。
在某些 DBMS(例如 Oracle)中,约束实际上可以提高某些查询的性能,因为优化器可以使用约束来获取有关数据结构的知识。有关一些示例,请参阅这篇 Oracle 杂志文章。
我想说所有必需的约束都必须在数据库中。外键约束防止不可用的数据。拥有它们并不好——除非您想要一个无用的数据库,否则它们是必需的。外键可能会损害删除和更新的性能,但这没关系。是花一点时间进行删除(或告诉应用程序不要删除此人,因为他在系统中有订单)还是删除用户但不删除他的数据?缺少外键可能会导致查询数据时出现意外且通常很严重的问题。例如,成本报告可能取决于所有具有相关数据的表,因此可能无法显示重要数据,因为一个或多个表没有可连接的内容。
唯一约束也是任何体面数据库的要求。如果一个字段或一组字段必须是唯一的,那么无法在数据库级别定义它会产生极难修复的数据问题。
你没有提到其他限制,但你应该。必须始终应用于表中所有数据的任何业务规则都应始终通过数据类型(例如不接受 '02\31\2009' 作为有效日期的数据时间数据类型)、约束(例如一个不允许字段的值大于 100)或通过触发器的方法是逻辑非常复杂,无法通过普通约束处理。(如果您不知道自己在做什么,触发器很难编写,因此如果您的逻辑如此复杂,那么您希望团队中有一名数据库专业人员。)顺序很重要。数据类型是第一选择,其次是约束,最后是触发器。
当您使用共享数据库集成多个应用程序时,完整性约束尤为重要。
您可能能够在单个应用程序的代码中正确管理数据完整性(即使您不这样做,至少损坏的数据只会影响该应用程序),但是对于多个应用程序,它会变得很麻烦(并且至少是多余的)。
“哦,如果数据约束发生变化,那是数据库配置问题,而不是代码更改问题。”
除非它是从设计中消失的约束。在这种情况下,肯定会产生代码影响,因为可能已经编写了一些代码,这取决于已删除的约束。
在“放松”或“删除”任何声明的约束时,必须始终考虑到这一点。
除此之外,你当然是完全正确的。