SQL：应该在哪里定义主键答案

【问题标题】：SQL: Where should the Primary Key be definedSQL：应该在哪里定义主键
【发布时间】：2011-03-16 18:35:01
【问题描述】：

我正在创建一个包含多个 sql 文件的数据库 1个文件创建表。 1 个文件添加了约束。 1 个文件删除了约束。

主键是一个约束，但是有人告诉我在表定义中定义你的主键，但没有给出原因。

将主键定义为可以添加和删除的约束更好还是在表定义中更好。

我目前的想法是在表定义中这样做，因为将其作为可移动约束可能会导致重复键出现一些可怕的问题。但是删除约束无论如何都可能导致严重的问题，因此预计如果有人确实删除了主键，他们会采取适当的措施来避免问题，因为他们应该在任何其他数据输入中遇到问题

【问题讨论】：

我们通常在每个表的一个脚本中为每个对象和所有相关的约束、索引等编写脚本，并将该脚本保存在源代码管理中。它删除现有对象，然后在最后重新创建。对于更高版本，我们可能有一个 alter table 脚本，它仅适用于该版本的更改。

标签： sql primary-key theory

【解决方案1】：

主键是约束，但约束不一定是主键。除了做一些重大的数据库手术外，永远都不需要删除主键。

与表一起定义主键是一种很好的做法 - 如果将表和键定义分开，则会打开丢失或忘记键定义的窗口。鉴于任何体面的数据库设计都完全依赖于一致的键，因此您绝不希望主键无法正常运行。

【讨论】：

您可能需要在初始开发期间随着您的设计发展或支持对业务需求的更改而删除或更改密钥。我会将每个关键约束放在它自己的脚本中。一些数据库变更管理工具还坚持每个对象都有单独的脚本。

【解决方案2】：

从可维护性的角度来看，我会说最好在表定义中包含主键，因为它可以很好地指示表最有可能用于什么。

其他约束也很重要，你的论点成立。

【讨论】：

【解决方案3】：

所有这些都是特定于平台的，但主键是一个逻辑概念，而约束（或唯一索引或其他）是实现“主键”逻辑概念的物理事物。这是争论将其与表本身放在一起的另一个原因——它是逻辑上的主页——而不是约束文件。

【讨论】：

【解决方案4】：

对于有效的源代码控制，为每个对象（包括约束）设置一个单独的脚本通常是有意义的。这样您就可以单独跟踪每个对象的更改。

【讨论】：

【解决方案5】：

将与表相关的所有内容保存在一个文件中具有一定的逻辑意义——列定义、键、索引、触发器等。如果您永远不必从 SQL 重建一个非常大的数据库，那么几乎所有这些都可以正常工作时间。几次效果不佳可能不值得更改将所有相关内容放在一个文件中的过程。

但是，如果您必须重建一个非常大的数据库，或者如果您需要将数据库移动到不同的服务器上进行测试，或者如果您只是想摆弄一些东西，那么将它们分开是有意义的。在 PostgreSQL 中，我们像这样分解事物。所有这些文件都在版本控制之下。

一个文件中的所有 CREATE DOMAIN 语句。
每个 CREATE TABLE 语句都在一个单独的文件中。该文件包括除 FOREIGN KEY 约束之外的所有约束，以 ALTER TABLE 语句表示。（稍后会详细介绍。）
每个表的 FOREIGN KEY 约束在一个单独的文件中。
每个表的非键列索引在一个单独的文件中。
每个表的触发器在一个单独的文件中。（如果一个表有三个触发器，则三个触发器都放在一个文件中。）
每个表的数据在一个单独的文件中。（仅适用于在使数据库联机之前加载的表。）
每个表的规则在一个单独的文件中。
每个函数都在一个单独的文件中。（函数相当于 PostgreSQL 的存储过程。）

没有外键约束，我们可以按任何顺序加载表。加载表后，我们可以运行一个脚本来重建所有外键。 makefile 负责将正确的单个文件捆绑在一起。（因为它们是单独的文件，我们可以根据需要单独运行它们。）

如果没有约束，表的加载速度会更快。我说过我们将每个 CREATE TABLE 语句放在一个单独的文件中。该文件包括除 FOREIGN KEY 约束之外的所有约束，以 ALTER TABLE 语句表示。您可以使用流媒体编辑器sed 将这些文件分成两部分。一件有列定义；另一部分包含所有“ALTER TABLE ADD CONSTRAINT”语句。 makefile 负责拆分源文件并将它们捆绑在一起——一个 SQL 文件中的所有表定义，以及另一个中的所有 ALTER TABLE 语句。然后我们可以运行一个脚本来创建所有表，加载表，然后运行一个脚本来重建所有约束。

make 是你的朋友。

【讨论】：