Question

我正在学习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命名有什么好处？

Answer 1

为约束提供显式名称有很多好处。举几个例子：

您可以按名称删除它们。
如果您在选择时使用约定名称，然后你可以收集它们从元表中处理它们编程。

Answer 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

Answer 3

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

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

Answer 4

约束作为SQL中的对象，与PK，FK，Table或几乎任何其他东西相同。如果为约束命名，则可以根据需要轻松删除它，例如在某种批量数据导入期间。如果你没有给它命名，你仍然可以删除它，但是你必须找出SQL会给它的自动生成的名称。

Answer 5

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

Answer 6

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

架构比较工具

如果您需要比较DEV和UT等环境以查看差异，则表级可能会出现“假阳性”，这确实很烦人。表定义在字面上是相同的，但是由于自动生成的名称不同，因此将其标记为更改。

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

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

如果您正在使用基于状态的迁移工具（例如MS SSDT），然后在将生成的更改应用于PRODUCTION之前手动对其进行检查，则希望最终脚本尽可能短。

有一百行，它们确实放下了约束并以不同的名称创建它，这是“ noise”。可以从该工具禁用某些约束，而某些约束仍将重新生成（DEFAULT / CHECK）。拥有明确的名称和良好的命名约定可以解决所有问题。

EIBTI

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

命名为CONSTRAINT的好处

6 个答案: