首页 文章

何时使用自动递增的主键,何时不使用?

提问于
浏览
50

我试图找出决定是否添加自动递增整数作为表的主键的“最佳实践” .

假设我有一个包含化学元素数据的表格 . 每个元素的原子序数是唯一的,永远不会改变 . 因此,不是为每列使用自动递增整数,而是使用原子序数可能更有意义,对吗?

如果我有一张书桌,那也是如此吗?我应该使用ISBN还是主键的自动递增整数?或者包含每个人的SSN的员工表?

7 回答

  • 13

    Stack Overflow上有很多已经解决的问题可以帮助您解决问题 . 见herehereherehere .

    您应该寻找的术语:surrogated keys .

    希望能帮助到你 .

  • 10

    这是一个备受争议的问题,双方都有很多情感 .

    在我看来,如果有一个好的,可用的自然键 - 比如ISBN - 我就用它 . 无论如何,我打算将它存储在数据库中 . 是的,自然键通常大于整数自动增量键,但我认为这个问题过于夸张 . 磁盘空间今天很便宜 . 我更担心它需要更长的时间来处理 . 如果你在谈论一个80字节的文本字段作为主键,我会说不 . 但是,如果您考虑使用10字节的ISBN而不是8字节的大整数,我无法想象这会带来很大的性能损失 .

    有时,自然键具有性能优势 . 例如,假设我想找到已售出的给定书籍的副本数量 . 我不关心Book主记录中的任何数据 . 如果主键是ISBN,我可以简单地写一下“select count()from sale where isbn ='143573338X'” . 如果我使用自动增量密钥,我将不得不进行连接以查找isbn,并且查询变得更复杂和更慢,例如“使用(bookid)从book join sale中选择count(),其中isbn ='143573338X' ” . (我可以向你保证,由于这个特定的ISBN适用于我的书,销售记录的数量非常少,所以加入和阅读一个额外的记录是一个很大的百分比差异!)

    自然键的另一个优点是,当您必须处理数据库并查看按键引用此表的记录时,很容易看到它们所指的记录 .

    另一方面,如果没有好的,明显的自然键,不要试图拼凑一个疯狂的 . 我看到人们试图通过将客户名字的前6个字母,他的出生年份和他的邮政编码连接在一起来制作一个自然的密钥,然后祈祷这将是独一无二的 . 那种愚蠢只会给自己制造麻烦 . 通常人们最终会接受一个序列号,以确保它的独特之处,那时,为什么还要费心呢?为什么不直接使用序列号作为键?

  • 2

    你已经有了这个想法 .

    如果您正在建模的项目中不存在唯一键,则应将自动增量用作唯一键 . 因此,对于Elements,您可以使用原子序号或书籍ISBN号 .

    但是如果人们在留言板上发布消息,那么这些消息需要一个唯一的ID,但不能自然包含,所以我们从列表中分配下一个数字 .

    在可能的情况下使用自然键是有意义的,只需记住将字段作为主键并确保为性能编制索引

  • 3

    我在自动递增整数方法时遇到的主要问题是当您导出数据以引入另一个数据库实例,甚至存档和还原操作时 . 由于整数与它引用的数据无关,因此在将数据还原或添加到现有数据库时无法确定是否存在重复项 . 如果你想在行中包含的数据和PK之间没有关系,我只会使用一个guid . 用户不太友好,但它解决了上述问题 .

  • 3

    关于使用ISBN和SSN,您必须考虑其他表中有多少行将通过外键引用这些行,因为这些ID将占用比整数更多的空间,因此可能导致磁盘空间浪费和可能更糟糕的是加入表现 .

  • 0

    我试图找出决定是否添加自动递增整数作为表的主键的“最佳实践” .

    Use it as a unique identifier with a dataset where the PKey is not part of user managed data.

    假设我有一个包含化学元素数据的表格 . 每个元素的原子序数是唯一的,永远不会改变 . 因此,不是为每列使用自动递增整数,而是使用原子序数可能更有意义,对吗?

    Yes.

    如果我有一张书桌,那也是如此吗?我应该使用ISBN还是主键的自动递增整数?或者包含每个员工的员工表人的SSN?

    ISBNs/SS#s are assigned by third-parties and because of their large storage size would be a highly inefficient way to uniquely identify a row. Remember, PKeys are useful when you join tables. Why use a large data format like an ISBN which would be numerous textual characters as the Unique identifier when a small and compact format like Integer is available?

  • 4

    我知道的老话题,但另外要考虑的是,鉴于大多数RDBMS使用PK在磁盘上布局块,使用自动递增PK只会大大增加您的争用 . 这对你的宝贝数据库来说可能不是一个问题,但是相信我它可能会在城市的大街上造成巨大的性能问题 .

    如果必须使用自动递增ID,可以考虑将其用作PK的一部分 . 最后坚持它以保持独特性.....

    此外,最好在跳到代理人之前用尽自然PK的所有可能性 . 人们通常对此很懒惰 .

相关问题