SQL:应该在哪里定义主键

时间:2011-03-16 18:35:02

标签: sql primary-key theory

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

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

最好将主键定义为可以添加和删除的约束,还是最好在表定义中执行它。

我目前的想法是在表定义中执行此操作,因为将其作为可移除约束进行操作可能会导致重复键出现一些可怕的问题。 但是,删除约束可能会导致严重的问题,所以如果有人确实丢弃了主键,他们就会采取适当的措施来避免出现任何其他数据录入的问题

5 个答案:

答案 0 :(得分:3)

主键是约束,但约束不一定是主键。如果不做一些重要的数据库手术,就永远不需要丢弃主键。

将主键与表一起定义是一种很好的做法 - 如果将表和键定义分开,则会打开窗口,使键定义丢失或遗忘。鉴于任何体面的数据库设计完全取决于一致的密钥,您甚至不希望您的主键无法正常运行。

答案 1 :(得分:0)

从可维护性的角度来看,我会说最好在表定义中使用主键,因为它是表最有可能用于表的内容的一个非常好的指示。

其他约束也很重要,但你的论点仍然存在。

答案 2 :(得分:0)

所有这些都是特定于平台的,但主键是逻辑概念,而约束(或唯一索引,或其他)是实现“主键”的逻辑概念的物理事物。 这是另一个争论将它与表本身 - 它是逻辑主页 - 而不是约束文件的理由。

答案 3 :(得分:0)

对于有效的源代码控制,每个对象都有一个单独的脚本(包括约束)通常是有意义的。这样,您可以单独跟踪每个对象的更改。

答案 4 :(得分:0)

将一个表中的所有内容保存在一个文件中有一定的逻辑意义 - 列定义,键,索引,触发器等。如果您不必从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语句放在另一个SQL文件中。然后我们可以运行单个脚本来创建所有表,加载表,然后运行单个脚本来重建所有约束。

make是你的朋友。