我正在用几个sql文件创建数据库 1个文件创建表。 1个文件添加约束。 1个文件丢弃约束。SQL：应该在哪里定义主键
主要是一个约束，但我已经告诉某人在表定义中定义主键，但没有给出原因。
是更好地定义主键可以添加和删除或为它更好地做到这一点在表定义的约束。
我现在的想法是做表中的定义，因为这样做是可拆卸的约束可能会导致重复键一些可怕的问题。 但是，放弃约束可能会导致严重问题，因此预计如果有人确实放弃了主键，他们将采取适当的措施来避免问题，因为他们应该有任何其他数据输入
主键是一个约束，但约束不一定是主键。在做一些大型数据库手术的时候，永远不应该放弃主键。
与表一起定义主键是很好的做法 - 如果你分开的表和钥匙的定义，在打开的窗口中的关键定义迷路或遗忘。鉴于任何体面的数据库设计都完全依赖于一致的密钥，所以您永远不希望主键无法正常工作。
您可能需要在初始开发期间随着设计的演变或支持对业务需求的更改而删除或更改密钥。我会把每个关键约束放在它自己的脚本中。一些数据库变更管理工具还坚持每个对象都有独立的脚本。 – sqlvogel 2011-03-17 00:45:09
从可维护性的角度来看，我会说在表格定义中使用主键更好，因为它是最有可能用于表格的一个很好的指标。
其他约束条件同样重要，尽管您的论点仍然存在。
所有这一切都有些特定的平台，但主键是一个逻辑概念，而约束（或唯一索引，或其他）是实现“主键”的逻辑概念的物理事情。 这是另一个争论与表本身 - 它是合乎逻辑的家 - 而不是约束文件的原因。
对于有效的源代码控制，每个对象（包括约束）都有一个单独的脚本通常是有意义的。这样你可以分别追踪每个对象的变化。
有在保持在一个文件中涉及到的表的一切一定的逻辑意义 - 列定义，键，索引，触发器等。如果你从来没有重建从SQL非常大的数据库，这将正常工作几乎每时每刻。有几次它不能很好地工作可能不值得改变将所有相关事物放在一个文件中的过程。
但是，如果您必须重建一个非常大的数据库，或者如果您需要将数据库移动到另一台服务器上进行测试，或者您只是想摆弄东西，那么分离它是有道理的。在PostgreSQL中，我们像这样分解事情。所有这些文件都受版本控制。
没有外键约束，我们可以按任意顺序加载表。在加载表之后，我们可以运行一个脚本来重建所有外键。 makefile负责将正确的单个文件捆绑在一起。 （由于它们是单独的文件，因此如果需要，我们可以单独运行它们。）
如果表没有约束，表加载速度更快。我说过我们把每个CREATE TABLE语句放在一个单独的文件中。该文件包含除FOREIGN KEY约束外的所有约束，表示为ALTER TABLE语句。您可以使用流媒体编辑器sed将这些文件分成两部分。一件有列定义;另一块具有所有'ALTER TABLE ADD CONSTRAINT'语句。 makefile负责分割源文件并将它们捆绑在一起 - 一个SQL文件中的所有表定义以及另一个中的所有ALTER TABLE语句。然后，我们可以运行一个脚本来创建所有表，加载表，然后运行一个脚本来重建所有约束。
make是你的朋友。
我们通常将每个对象以及所有关联的约束，索引等脚本编写到每个表的一个脚本中，并将该脚本保存在源代码管理中。它会删除现有对象，然后在最后重新创建。对于以后的版本，我们可能会有一个alter table脚本，它只适用于该版本的更改。 – HLGEM 2011-03-16 19:34:43