我正在创建一个数据库表，并且没有为其分配逻辑主键 . 所以，我正考虑在没有主键的情况下离开它，但我对此感到有点愧疚 . 我是不是该？
Should each and every table have a primary key?
编辑：好的，好的......我已经创建了主键！你现在高兴了？ :)
为了让它成为未来证明你真的应该 . 如果你想复制它，你需要一个 . 如果你想把它加入到另一张 table 上，那么你的生活（以及那些必须在明年维持它们的愚蠢者）将会变得如此简单 .
如果您正在使用Hibernate，则无法在没有主键的情况下创建实体 . 如果您使用的是使用普通sql / ddl脚本创建的现有数据库，并且未添加主键，则此问题可能会产生问题
除了一些非常罕见的情况（可能是多对多关系表，或者您临时用于批量加载大量数据的表），我会说：
如果它没有主键，则不是表格！
渣
几乎任何时候我都创建了一个没有主键的表，以为我不需要一个，我最后回去添加一个 . 我现在甚至使用自动生成的标识字段创建连接表，我将其用作主键 .
您是否需要将此表连接到其他表？您需要一种方法来唯一识别记录吗？如果答案是肯定的，那么您需要一个主键 . 假设您的数据类似于客户表，其中包含客户的名称 . 可能没有自然键，因为您需要地址，电子邮件，电话号码等来确定这个Sally Smith是否与Sally Smith不同，并且您将该信息存储在相关表格中，因为此人可以拥有多个手机，addesses假设莎莉史密斯与约翰琼斯结婚并成为莎莉琼斯 . 如果您在桌面上没有人工钥匙，当您更新名称时，您只需将7 Sally Smiths更改为Sally Jones，即使其中只有一人结婚并更改了姓名 . 当然，在这种情况下，如果没有人工关键，你怎么知道哪个莎莉史密斯住在芝加哥，哪个住在洛杉矶？
你说你没有自然键，因此你没有任何字段组合来制作独特的，这使得人工关键变得至关重要 .
我发现任何时候我都没有自然键，人工键是保持数据完整性的绝对必要条件 . 如果您有自然键，则可以将其用作关键字段 . 但个人除非自然键是一个字段，否则我仍然更喜欢自然键上的人工键和唯一索引 . 如果你没有放入，你会后悔的 .
我总是有一把主键，即使在开始时我还没有考虑到它的目的 . 曾经有几次我最终需要一个没有一个PK的表格中的PK，以后再把它放进去总是比较麻烦 . 我认为总是包括一个更多的好处 .
我负责维护离岸开发团队创建的应用程序 . 现在我在应用程序中遇到各种问题，因为原始数据库模式在某些表上不包含PRIMARY KEYS . 所以请不要让其他人因为你的糟糕设计而受苦 . 在表上使用主键始终是个好主意 .
总之，没有 . 但是，您需要记住某些客户端访问CRUD操作需要它 . 为了将来打样，我倾向于总是使用主键 .
我知道，为了在.NET中使用gridview的某些功能，您需要一个主键，以便gridview知道哪一行需要更新/删除 . 一般做法应该是拥有主键或主键群集 . 我个人更喜欢前者 .
总是最好有一把主键 . 这样它符合first normal form并允许您沿着database normalization路径继续 .
正如其他人所说，有一些原因没有主键，但如果有主键，大多数都不会受到伤害
只需添加它，稍后当你没有（选择，删除，链接等）时，你会后悔的 .
在每张 table 上都有一个PK是一个好习惯，但它不是必须的 . 根据您的需要，您很可能需要一个唯一索引和/或聚簇索引（PK或不是PK） .
查看联机丛书中的主键和聚簇索引部分（适用于SQL Server）
“PRIMARY KEY约束标识具有唯一标识表中行的值的列或列集 . 表中没有两行可以具有相同的主键值 . 您不能为主键中的任何列输入NULL . 我们建议使用一个小的整数列作为主键 . 每个表都应该有一个主键 . 一个符合主键值的列或列组合被称为候选键 .
但是还要检查一下：http://www.aisintl.com/case/primary_and_foreign_key.html
简答： yes .
答案很长：
你需要你的 table 可以加入某些东西
如果希望对表进行群集，则需要某种主键 .
如果您的桌面设计不需要主键，请重新考虑您的设计：最有可能的是，您遗漏了一些东西 . 为何保留相同的记录？
在MySQL中，InnoDB存储引擎总是会创建一个主键，如果您没有明确指定它，从而创建一个您无权访问的额外列 .
请注意，主键可以是复合键 .
如果您有多对多链接表，则在链接中涉及的所有字段上创建主键 . 因此，您可以确保没有两条或更多条描述一条链接的记录 .
除了逻辑一致性问题之外，大多数RDBMS引擎都将受益于将这些字段包含在唯一索引中 .
由于任何主键都涉及创建唯一索引，因此您应该声明它并获得逻辑一致性和性能 .
请参阅我的博客中的这篇文章，了解为什么您应该始终为唯一数据创建唯一索引：
P.S. 有一些非常非常特殊的情况，您不需要主键 .
它们主要包括由于性能原因而没有任何索引的日志表 .
13 回答
为了让它成为未来证明你真的应该 . 如果你想复制它，你需要一个 . 如果你想把它加入到另一张 table 上，那么你的生活（以及那些必须在明年维持它们的愚蠢者）将会变得如此简单 .
如果您正在使用Hibernate，则无法在没有主键的情况下创建实体 . 如果您使用的是使用普通sql / ddl脚本创建的现有数据库，并且未添加主键，则此问题可能会产生问题
除了一些非常罕见的情况（可能是多对多关系表，或者您临时用于批量加载大量数据的表），我会说：
渣
几乎任何时候我都创建了一个没有主键的表，以为我不需要一个，我最后回去添加一个 . 我现在甚至使用自动生成的标识字段创建连接表，我将其用作主键 .
您是否需要将此表连接到其他表？您需要一种方法来唯一识别记录吗？如果答案是肯定的，那么您需要一个主键 . 假设您的数据类似于客户表，其中包含客户的名称 . 可能没有自然键，因为您需要地址，电子邮件，电话号码等来确定这个Sally Smith是否与Sally Smith不同，并且您将该信息存储在相关表格中，因为此人可以拥有多个手机，addesses假设莎莉史密斯与约翰琼斯结婚并成为莎莉琼斯 . 如果您在桌面上没有人工钥匙，当您更新名称时，您只需将7 Sally Smiths更改为Sally Jones，即使其中只有一人结婚并更改了姓名 . 当然，在这种情况下，如果没有人工关键，你怎么知道哪个莎莉史密斯住在芝加哥，哪个住在洛杉矶？
你说你没有自然键，因此你没有任何字段组合来制作独特的，这使得人工关键变得至关重要 .
我发现任何时候我都没有自然键，人工键是保持数据完整性的绝对必要条件 . 如果您有自然键，则可以将其用作关键字段 . 但个人除非自然键是一个字段，否则我仍然更喜欢自然键上的人工键和唯一索引 . 如果你没有放入，你会后悔的 .
我总是有一把主键，即使在开始时我还没有考虑到它的目的 . 曾经有几次我最终需要一个没有一个PK的表格中的PK，以后再把它放进去总是比较麻烦 . 我认为总是包括一个更多的好处 .
我负责维护离岸开发团队创建的应用程序 . 现在我在应用程序中遇到各种问题，因为原始数据库模式在某些表上不包含PRIMARY KEYS . 所以请不要让其他人因为你的糟糕设计而受苦 . 在表上使用主键始终是个好主意 .
总之，没有 . 但是，您需要记住某些客户端访问CRUD操作需要它 . 为了将来打样，我倾向于总是使用主键 .
我知道，为了在.NET中使用gridview的某些功能，您需要一个主键，以便gridview知道哪一行需要更新/删除 . 一般做法应该是拥有主键或主键群集 . 我个人更喜欢前者 .
总是最好有一把主键 . 这样它符合first normal form并允许您沿着database normalization路径继续 .
正如其他人所说，有一些原因没有主键，但如果有主键，大多数都不会受到伤害
只需添加它，稍后当你没有（选择，删除，链接等）时，你会后悔的 .
在每张 table 上都有一个PK是一个好习惯，但它不是必须的 . 根据您的需要，您很可能需要一个唯一索引和/或聚簇索引（PK或不是PK） .
查看联机丛书中的主键和聚簇索引部分（适用于SQL Server）
“PRIMARY KEY约束标识具有唯一标识表中行的值的列或列集 . 表中没有两行可以具有相同的主键值 . 您不能为主键中的任何列输入NULL . 我们建议使用一个小的整数列作为主键 . 每个表都应该有一个主键 . 一个符合主键值的列或列组合被称为候选键 .
但是还要检查一下：http://www.aisintl.com/case/primary_and_foreign_key.html
简答： yes .
答案很长：
你需要你的 table 可以加入某些东西
如果希望对表进行群集，则需要某种主键 .
如果您的桌面设计不需要主键，请重新考虑您的设计：最有可能的是，您遗漏了一些东西 . 为何保留相同的记录？
在MySQL中，InnoDB存储引擎总是会创建一个主键，如果您没有明确指定它，从而创建一个您无权访问的额外列 .
请注意，主键可以是复合键 .
如果您有多对多链接表，则在链接中涉及的所有字段上创建主键 . 因此，您可以确保没有两条或更多条描述一条链接的记录 .
除了逻辑一致性问题之外，大多数RDBMS引擎都将受益于将这些字段包含在唯一索引中 .
由于任何主键都涉及创建唯一索引，因此您应该声明它并获得逻辑一致性和性能 .
请参阅我的博客中的这篇文章，了解为什么您应该始终为唯一数据创建唯一索引：
P.S. 有一些非常非常特殊的情况，您不需要主键 .
它们主要包括由于性能原因而没有任何索引的日志表 .