命名约束好处答案

【问题标题】：Named CONSTRAINT benefits命名约束好处
【发布时间】：2011-05-05 12:48:07
【问题描述】：

我正在学习 SQL，偶然发现了 CONSTRAINT。我可以这样定义它们：

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)
);

我为什么要给他们起名字？或者为什么我应该或不应该给他们名字？正如我在这个例子中看到的，在我脑海中的大多数情况下，我都不能重用它们。那么给 CONSTRAINT 命名有什么好处呢？

【问题讨论】：

标签： sql constraints

【解决方案1】：

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

您可以按名称删除它们。
如果您在选择名字，然后你可以收集它们从元表中处理它们以编程方式。

【讨论】：

【解决方案2】：

看来您使用的是 PostgreSQL，但实际上差异并没有那么大。

这是因为 PostgreSQL 中系统生成的名称实际上是有一定意义的。但是“positive_price”仍然比“foo_price_check”更容易理解：

想想哪个错误信息更好理解：
new row for relation "foo" violates check constraint "foo_price_check"
或
new row for relation "foo" violates check constraint "positive_price"

在 Oracle 中，情况更糟，因为生成的系统不包含任何提示错误：
ORA-02290: check constraint (SYS_C0024109) violated
与
ORA-02290: check constraint (POSITIVE_PRICE) violated

【讨论】：

SQL Server 处于中间位置，但也存在与 Oracle 相同的问题。

【解决方案3】：

您没有指定 RDBMS。以下几点适用于 SQL Server，我猜其他 RDBMS 也很可能。

您需要知道drop 的约束名称，约束的名称也会出现在约束违反错误消息中，因此给出明确的名称可以使这些更有意义（SQL Server 将自动为约束，它不会告诉你约束的意图）。

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

如果您的约束被违反，在错误消息中包含它的名称有助于调试它并向用户显示错误消息。

【讨论】：

【解决方案6】：

命名约束在场景中非常有用。以下是我目前遇到的：

架构比较工具

如果您需要比较 DEV 和 UT 之类的环境来查看差异，您可能会在表格级别得到“误报”，这真的很烦人。表定义字面上相同，但由于自动生成的名称不同，因此将其标记为更改。

是的，一些工具允许跳过/忽略约束名称，但不是全部。

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

如果您使用 MS SSDT 等基于状态的迁移工具，然后在将生成的更改应用到 PRODUCTION 之前手动查看生成的更改，您希望最终脚本尽可能短。

有一百行，确实删除约束并以不同的名称创建它是“噪音”。该工具可以禁用某些约束，但仍会重新生成一些约束（DEFAULT/CHECK）。拥有明确的名称和良好的命名约定可以解决所有问题。

EIBTI

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

【讨论】：