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

Question

虽然，这可能看起来是基于主要意见的问题，但并不是绝对如此。

我想知道在SQL中创建约束的每一种可能约定的利弊是什么。由于我使用SQL Server，我将展示三个创建主键约束的示例，我熟悉这些示例：

1. CREATE TABLE Persons (Id int NOT NULL PRIMARY KEY);
   • +：简明
   • -：生成半随机名称
   • -：不能覆盖多列

​

1. CREATE TABLE Persons (Id int NOT NULL, CONSTRAINT PK_Persons_Id PRIMARY KEY(Id));
   • +：填鸭式简洁
   • +：可以覆盖多列
   • +：开发人员事先知道什么是主键，pk的名称是什么
   • -：降低创建语句的可重用性

​

1. CREATE TABLE Persons (Id int NOT NULL); ALTER TABLE Persons ADD CONSTRAINT PK_Persons_Id PRIMARY KEY (Id);
   • +：将表创建语句与其约束分离，这可能会增加一些好处，比如代码可重用性。
   • -：也许它掩盖了表模式，因为开发人员事先不知道什么是主键

​

这些都是利与弊，我到目前为止已经发现了。也许更有经验的开发人员可以指出其他有助于做出最佳决策的因素，同时在开发和生产环境中创建主要的关键和其他约束。例如：

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

我相信我们可以分享一种语法什么时候比另一种语法有实际好处的知识。

Answer 1

从操作的角度来看:给每个约束赋予它自己的唯一名称，这样您以后就可以通过引用它的名称来更改或删除该约束。

此外，与唯一索引相比，我更喜欢和普通索引加上一个命名的唯一约束，所以在DBMS支持时，我可以在不丢失索引的情况下删除该约束。实际上，我只在Oracle上看到过这样的情况:在那里，您可以使用一个普通(非唯一)索引来支持一个唯一约束。删除约束时，索引将保持不变。这对于稳定的执行计划(“计划稳定性”)非常重要。不幸的是，在当前版本中，Server和PostgreSQL似乎都不支持此功能。

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