约束命名的目的是什么答案

【问题标题】：What is the purpose of constraint naming约束命名的目的是什么
【发布时间】：2010-11-26 17:09:12
【问题描述】：

命名约束（唯一、主键、外键）的目的是什么？

假设我有一个使用自然键作为主键的表：

CREATE TABLE Order
(
    LoginName        VARCHAR(50)    NOT NULL,
    ProductName      VARCHAR(50)    NOT NULL,
    NumberOrdered    INT            NOT NULL,
    OrderDateTime    DATETIME       NOT NULL,
    PRIMARY KEY(LoginName, OrderDateTime)
);

命名我的 PK 有什么好处（如果有的话）？

例如。替换：

    PRIMARY KEY(LoginName, OrderDateTime)

与：

    CONSTRAINT Order_PK PRIMARY KEY(LoginName, OrderDateTime)

对不起，如果我的数据模型不是最好的，我是新手！

【问题讨论】：

也许稍后使用名称来引用约束..就像你想删除\编辑它一样？

标签： sql database constraints naming

【解决方案1】：

为了在将来识别约束（例如，您想在将来删除它），它应该有一个唯一的名称。如果您不为其指定名称，数据库引擎可能会为您分配一个奇怪的名称（例如，包含随机内容以确保唯一性）。

【讨论】：

这是否意味着命名它只是为了人们可以更容易地识别约束？换句话说，无论您是否命名约束，以任何方式（或影响）DBMS 都没有关系？您不能出于某种目的在代码中使用它吗？抱歉，如果不清楚。
只是一个名字。该名称没有功能上的区别。如果您将来想在代码中引用它，那么名称当然很重要。这就像说，代码中的变量名。
就像列 names 没有任何区别。如果它们描述了它们是什么（“ProductId”而不是“BJZ0_340”或“Fred”），它们会更有用。
能否在 REFERENCES 语句中使用约束名称？
没有。例如，您可以在ALTER TABLE DROP CONSTRAINT [name] 中使用它。

【解决方案2】：

它可以帮助人们快速了解约束在做什么，而无需查看实际的约束，因为名称为您提供了所需的所有信息。

所以，我知道它是主键、唯一键还是默认键，以及所涉及的表和可能的列。

【讨论】：

【解决方案3】：

这让 DBA 很高兴，因此他们让您的架构定义进入生产数据库。

【讨论】：

哈哈...是的，我想这是最重要的原因：P

【解决方案4】：

当您的代码随机违反某些外键约束时，它肯定会节省调试时间以确定它是哪一个。命名它们可以大大简化插入和更新的调试。

【讨论】：

【解决方案5】：

这里有一些非常基本的原因。

(1) 如果查询（插入、更新、删除）违反了约束，SQL 将生成包含约束名称的错误消息。如果约束名称清晰且具有描述性，则错误消息将更容易理解；如果约束名称是一个随机的基于 guid 的名称，那就不太清楚了。特别是对于最终用户，他们会（好吧，可能）打电话给您并询问“FK__B__B_COL1__75435199”是什么意思。

(2) 如果将来需要修改约束（是的，它确实发生了），如果你不知道它的名字是很难做到的。（ALTER TABLE MyTable drop CONSTRAINT um...）如果您“从头开始”创建多个数据库实例并使用系统生成的默认名称，则没有两个名称会匹配。

(3) 如果支持您的代码的人（也称为 DBA）不得不在周日凌晨 3 点浪费大量无意义的时间处理案例 (1) 或案例 (2)，那么他们很可能在识别代码来自何处并能够做出相应反应的位置。

【讨论】：

回复：“特别是对于最终用户，他们会（好吧，可能）打电话给您并询问“FK__B__B_COL1__75435199”是什么意思。” -- 我会说即使对于开发人员来说，看到“fk_payment_rental”之类的东西也更有用。

【解决方案6】：

通过正确命名所有约束，您可以快速将特定约束与我们的数据模型相关联。这给了我们两个真正的优势：

我们可以快速识别并修复任何错误。
我们可以可靠地修改或删除约束。

【讨论】：

【解决方案7】：

通过命名约束，您可以区分违反它们的情况。这不仅对管理员和开发人员有用，而且您的程序也可以使用约束名称。这比尝试解析错误消息要强大得多。通过使用约束名称，您的程序可以根据违反的约束做出不同的反应。

约束名称对于以用户的语言显示适当的错误消息也非常有用，其中提到了哪个字段导致了约束冲突，而不是仅仅从数据库服务器向用户转发一个神秘的错误消息。

在how to do this with PostgreSQL and Java 上查看我的回答。

【讨论】：

【解决方案8】：

虽然 OP 的示例使用了一个永久表，但请记住，临时表上的命名约束的行为类似于永久表上的命名约束（即，您不能有多个会话使用完全相同的代码处理临时表，而不生成错误，因为约束的名称相同）。因为命名约束必须是唯一的，如果您绝对必须在临时表上命名约束，请尝试在其末尾使用某种随机 GUID（如 SELECT NEWID() ）以确保它将在会话中唯一命名。

【讨论】：

【解决方案9】：

命名约束的另一个好理由是，如果您在数据库架构上使用版本控制。在这种情况下，如果您必须使用默认数据库命名（在我的情况下为 SQL Server）删除并重新创建约束，那么您将看到提交版本和工作副本之间的差异，因为它将具有新生成的名称。为约束指定一个明确的名称将避免这被标记为更改。

【讨论】：