因此，我始终被告知，使用表格指定主键是绝对必要的。我一直在做一些工作，遇到主键的唯一约束会阻止我添加所需的数据。
如果有一个示例情况，表格是用字段构建的：
Age, First Name, Last Name, Country, Race, Gender
如果正在输入TON数据，那么所有这些字段都不一定唯一地标识一行，并且我不需要跨所有列的索引。这里唯一的解决方案是创建一个自动递增ID字段吗？没有小学可以吗？
答案 0 :(得分：5)
并不总是需要拥有主键，大多数DBMS＆＃39;将允许您构建一个没有一个（a）的表。
但这并不一定意味着它是一个好主意。考虑一下您想要使用该数据的情况。现在想想你是否有两个来自珀斯的两个二十岁的澳大利亚男子鲍勃史密斯。
如果没有唯一约束，您可以将这两行放入表格中，但她可以轻松完成。你怎么知道将来要使用哪一个？ （b）中
现在，如果您只想存储一个或多个人符合这些条件的事实，您只需要存储一个行。但是，您可能拥有一个由所有列组成的复合主键。
如果您想要存储关于此人的其他信息（例如，在＃24; 2048＆＃34; iPhone上的游戏中获得最高分），那么您不想要在整个行中使用主键，就在您提到的列中。
不幸的是，这意味着毫无疑问，鲍勃史密斯的两个人都试图将他们的高分写入数据库，但却发现其中一人丢失了他们的信息。
如果你想在表格中同时使用它们并且仍然希望允许上面提到的可能性（两个人在你提到的列中具有相同的属性）那么最好的选择是引入一个人工密钥，例如自动递增列，对于主键。这将允许您唯一地标识行，而不管其他列的相同程度。
人工密钥的另一个优点是，任意，它永远不需要改变被识别的东西。在您的示例中，如果您在主键中使用年龄，姓名，国籍或位置（c），这些 all 可能会发生变化，这意味着您需要调整任何引用这些行的外键。如果引用这些行的表使用不变的人工密钥，那将永远不会成为问题。
（a）在某些情况下，主键并没有真正为您带来任何性能优势，例如当表格特别小时（例如将整数1到12映射到月份名称） ）。
换句话说，全表扫描并不比索引慢得多。但是这些情况非常罕见，我可能仍然使用密钥，因为它更加一致（特别是因为使用密钥往往不会对性能产生影响 方式）。
（b）请记住，我们在这里练习而不是理论。虽然在实践中你可以创建一个没有主键的表，关系理论指出每一行必须是唯一可识别的，否则关系是不可能维持的。
C.J。与Codd一起成为关系数据库理论的祖先之一的日期，在数据库系统＆＃34;中介绍了关系表的规则，其中之一是：
记录具有唯一的标识符字段或字段组合，称为主键。
因此，就关系理论而言，每个表都必须有一个主键，即使它在实践中并不总是需要。
（c） 特别是年龄，保证每年都会改变，直到你死了，所以也许出生日期可能是该专栏的更好选择。
答案 1 :(得分：1)
通常，您应该避免通过数据库扩散ID主键字段。
现在，这并不意味着您不应该拥有主键，您的主键可以是代理键或组合键。这就是你应该做的。
如果这些字段{年龄，名字，姓氏，国家，种族，性别}明确标识每一行，则由所有这些字段组成一个主键。
但如果没有，那么你必须有一些其他类型的信息来消除你的数据歧义。
您也可以，不指定任何类型的密钥，并假设该表为非规范化和冗余数据源......如果这是您需要的......！
答案 2 :(得分：1)
在您的帖子中，它看起来像代表person实体的表格。在这种情况下，不具备PK将唯一地确定每个人实体。我建议，在桌子上有一个主键，它将唯一地确定每个人的记录。
您可以创建AUTO_INCREMENT ID列（合成ID列）
（OR）
您可以在表格中组合多个列，这些列可以唯一地确定所有其他字段，例如(First Name, Last Name)可能会使其成为复合主键，但也可能会发生冲突，因为可能有多个人具有相同的全名（名字+姓氏）。