我有一张需要2个字段的表。一个是外键，另一个不一定是唯一的。除了阅读“每个需要的每个表都需要一个主键”之外，我确实没有理由找到主键。
编辑：
这里有一些好主意。
为了清楚起见，我将举一个类似于我的数据库需求的例子。
假设有一个包含产品类型，数量，成本和制造商的表格。
产品类型并不总是唯一的（例如，MP3播放器），但制造商/产品类型将是唯一的（例如，Apple MP3播放器）。忘记制造商为这个例子制作的各种型号。为方便起见，此表具有自动增量主键。
我给出了一个积分值并记录这些产品的搜索频率，添加到购物车中，并购买以便在热门商品列表中显示。
我现在铺设的方式是在第二个表中，FK指向主表，第二列表示该项目获得的“流行点数”总数。
这里看到的答案让我觉得也许我应该在我的主要产品表中添加一个“点”列，以便我可以跟踪那里......但这似乎我没有足够规范我的数据库
我的问题是我目前大多只是一个爱好者，为了学习而这样做，并且没有DBA的奢侈品告诉我如何设置我的表，所以我必须学习编码方面和数据库方面。
答案 0 :(得分：3)
您必须区分primary key和surrogate key。自动递增列将是后者的特定情况。因此，你的问题有两个：
第一个问题的答案是 YES ，除了在一些特殊情况下（多对多关系的关联表可以说是这种特殊情况的一个例子）。这样做的原因是，您通常需要能够（如果不是现在，将来）能够始终解决该表的各个行 - 例如，更新/删除。
第二个问题的答案是否。如果您的表代表核心业务实体，那么OR可以从多对一关联引用，具有代理键可能是个好主意;但是不绝对必要。
有些不清楚你的桌子的功能是什么;从你的描述中听起来它有“值集合”语义（FK到“主”表+值）。在这种情况下，某些ORM不支持代理密钥;如果这是提示你的问题的话，可以让代理人（或者甚至是主要的包）关闭。
答案 1 :(得分：2)
为了拥有独特的东西和标识符，请请在每个表格中都有一个主键：）
它还有助于转发可比性，以防将来出现架构更改且2个值不再具有唯一性。此外，内存现在便宜得多，可以随意使用它们作为投资。 ;）
答案 2 :(得分：1)
我不确定其他字段是怎么样的......但我猜这是一个复合主键，这是基于FK和其他字段的确定...但是我再也不知道你的具体情况。
答案 3 :(得分：0)
这是一种与规范化相关的技术，也是一种很好的实践。由自动递增数字组成的密钥有许多好处：
答案 4 :(得分：0)
我想说在每张桌子上都有一些主键是绝对必要的。
有趣的是，维亚康姆公司的一位DBA曾告诉我，使用INT UNSIGNED或VARCHAR(n)作为MySQL的主键确实没有明显区别。这是对超过6400万行的用户表的引用。我相信n可以很大（＆lt; = 100），但我忘记了它们的限制。不幸的是，我没有任何经验数据支持这一点。
答案 5 :(得分：0)
您不必在每个表上都有主键，但最好将它们放在最佳实践中，因为它们在规范化的关系数据库设计中几乎总是必需的。如果您发现一堆表格，您认为不需要PK，那么您应该重新审视表格的设计/布局。要详细了解规范化see here.
我可以想到的几个场景，你可能不需要或想要在桌面上使用PK，这将是一个严格用于记录的表。 （以限制写入日志和维护唯一索引的性能下降）以及刚刚存储数据用于泵送应用程序以进行测试的场景。
答案 6 :(得分：0)
如果您没有理由，我会反对并说您不应该添加密钥。如果需要，可以在以后添加此列。
答案 7 :(得分：0)
严格来说，代理键不是必需的，但主键是。
许多人使用术语“主键”来表示单列，它是一个自动递增的整数。但这不是主键的准确定义。
主键是一列或多列上的约束，用于唯一标识每一行。是的，您需要某种方式来处理单个行。这是关系（也就是表格）的关键特征。
您说您有一个外键和另一个不唯一的列。但这两个专栏是否一致？如果是这样，您可以在这两列上声明主键约束。
定义另一个代理键（也称为伪代码 - 自动递增类型）是一种便利，因为有些人不喜欢在选择单行时必须引用两列。或者他们希望可以轻松地自由更改其他列中的值，而无需更改用于处理单个行的主键的值。