Sql 命名约束好处

我正在学习SQL，但在约束方面遇到了困难。我可以这样定义它们：

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CHECK (price > 0)
);

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CONSTRAINT positive_price CHECK (price > 0)
);

就像这样：

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CHECK (price > 0)
);

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CONSTRAINT positive_price CHECK (price > 0)
);

我为什么要给他们起名字？或者为什么我应该或者不应该给他们起名字？

---

正如我在这个例子中看到的，在我脑海中的大多数情况下，我不能重用它们。那么，为约束命名有什么好处呢？

您不需要指定RDBMS。以下几点适用于SQL Server，我想很可能也适用于其他RDBMS

---

您需要知道要删除的约束的名称，约束的名称也会出现在约束冲突错误消息中，因此给出一个明确的名称可以使其更有意义（SQL Server将自动为约束生成一个名称，该名称不会告诉您约束的意图）.

为约束指定明确的名称有很大的好处。仅举几个例子：

你可以按名字删除它们

如果在选择 姓名，然后您可以收集它们 从元表中提取并处理它们 以编程方式

---

约束作为SQL中的对象，其方式与PK、FK、表或几乎任何其他对象相同。如果为约束指定一个名称，则可以在需要时轻松删除它，例如在某种批量数据导入期间。如果不给它命名，您仍然可以删除它，但是您必须找到SQL将给它的自动生成名称。

如果违反了约束，在错误消息中包含它的名称有助于调试它并将错误消息呈现给用户。

您似乎正在使用PostgreSQL，但实际上差别并不大

这是因为在PostgreSQL中系统生成的名称实际上有些意义。但“正价格”比“foo\u价格检查”更容易理解：

想想哪条错误消息更容易理解：

关系“foo”的新行违反了检查约束“foo\u price\u check”

或

关系“foo”的新行违反了检查约束“正价格”

在Oracle中，情况更糟，因为生成的系统不包含任何错误提示：

ORA-02290:违反了检查约束（SYS_C0024109）

vs.

---

ORA-02290:检查违反的约束（正价格）

命名约束在某些情况下非常有用。以下是我到目前为止遇到的问题：

架构比较工具

若您需要比较环境（如DEV和UT）以查看差异，那个么在表级别上可能会出现“false positives”，这真的很烦人。表定义在字面上是相同的，但是因为自动生成的名称不同，所以它被标记为change

是的，有些工具允许跳过/忽略约束名称，但并非所有工具都允许

来自基于状态的迁移工具的部署脚本

如果您使用基于状态的迁移工具（如MS SSDT）的工具，然后在将生成的更改应用于生产之前手动检查这些更改，那么您希望最终脚本尽可能简短

有上百条线，可以删除约束并用不同的名称创建它，这就是“噪波”。一些约束可以从该工具中禁用，一些约束仍然重新生成（默认/检查）。拥有明确的名称和良好的命名约定可以解决所有问题

---

最后，但并非最不重要。明确化可以简化事情。如果您有明确的名称，您可以在不搜索系统/元数据视图的情况下引用数据库对象。

SQL Server是中间的某个地方，但也会遇到与Oracle相同的问题。