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