在 SQL 中创建约束的不同方法的优缺点是什么？

Question

尽管它看起来像是基于主要意见的问题，但并非绝对如此。

我想知道在 SQL 中创建约束的每个可能约定的优缺点是什么。由于我使用 SQL Server，因此我将展示三个我熟悉的创建主键约束的示例：

1. CREATE TABLE Persons (Id int NOT NULL PRIMARY KEY);
   • +：简洁
   • -: 生成半随机名称
   • -: 不能覆盖超过一栏
2. CREATE TABLE Persons (Id int NOT NULL, CONSTRAINT PK_Persons_Id PRIMARY KEY(Id));
   • +：简洁的中间
   • +：可以覆盖多列
   • +：开发者事先知道什么是主键，什么是pk的名字
   • -：降低创建语句的可重用性
3. CREATE TABLE Persons (Id int NOT NULL); ALTER TABLE Persons ADD CONSTRAINT PK_Persons_Id PRIMARY KEY (Id);
   • +：将表创建语句与其约束分开，这可能会增加一些好处，例如代码可重用性
   • -: 也许它掩盖了表模式，因为开发人员事先不知道什么是主键

这些都是优点和缺点，这是我目前发现的。也许更有经验的开发人员可以指出在开发和生产环境中创建主键和其他约束时可以帮助做出最佳决策的其他因素。例如：

• 开发人员并不总是事先知道将来会使用什么工具。也许有一些不支持某些语法的常用工具。
• 如果我们可以在不同的数据库上使用它，代码就可以重用。这可能是使用一种语法而不是另一种语法的论据。
• 也许有人遇到过这样的情况，他想要在其中定义没有约束的表创建语句以及出于什么原因。

我相信我们可以分享关于一种语法何时比另一种语法具有实际优势的知识。

Answer 1

从操作的角度来看：为每个约束赋予其唯一的名称，以便您稍后可以通过引用名称来更改或删除约束。

此外，我更喜欢普通索引加上命名唯一约束而不是唯一索引，因此当 DBMS 支持时，我可以稍后删除约束而不会丢失索引。实际上我只在 Oracle 上看到过这一点：在那里你可以用普通（非唯一）索引支持唯一约束。当删除约束时，索引保持不变。这对于稳定的执行计划（“计划稳定性”）非常重要。不幸的是，看起来 SQL Server 和 PostgreSQL 在当前版本中都不支持此功能。

使用单独命名的约束，区分数据库模式也更容易：您只需将按名称排序的所有表名称、列名称、索引名称和约束名称枚举到平面文件中即可。然后，您可以轻松地将其与参考文件进行比较，并寻找意外的差异。当您没有稳定的名称并且必须比较约束的语义时，这要困难得多。