SQL主键 - 是否有必要？

Question

我有一个项目列表。大多数这些物品都没有库存。 item表有id，name，description。项目数量存储在名为inventory的另一个表中。库存表具有item_id和库存商品的数量。

我是否需要库存表的主键？如果是这样，我应该使用串行密钥还是复合密钥？什么时候表没有主键？

编辑：谢谢大家提供的信息。我现在总是有主键，除非极少数例外。我还了解了有关串行与复合键的更多信息。

Answer 1

始终瞄准主键。

如果您不确定，请使用主键。

即使你99.99％肯定你不需要它，也有一个。正如我多年来从经验中学到的那样，需求发生了变化。

我能想到的唯一例子是多对多表，只有两个foreign_keys和超大（数亿行）表，每个字节都很重要。但即便如此，强烈建议使用单独的，独特的，无商业价值的密钥。

这里有一些更好的信息：
http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

在这里：
http://www.techrepublic.com/article/the-great-primary-key-debate/1045050
在这里：
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html
在这里：
Should I use composite primary keys or not?

在你的例子中，我肯定会有一个。

“不”拥有一个的决定应基于非常明确的需求和理解以及实际或预测（例如数量）问题。

调试和故障排除时会出现这种需求的一个很好的例子。就像在每个表中创建和更新列（我的另一个最喜欢的）一样，此信息最初可能不会被/用于前端，但是男孩可以帮助跟踪和解决问题。 （btw更新标记现在通常是 Ruby On Rails 等框架中的标准，它也适用于每个具有id字段的表的约定！）

Answer 2

一般情况下：每张桌子都应该有PK。至少每个表都应该有一些CLUSTER索引。 PK不能是一个特殊的列，但在系统（RDBMS）中没有唯一标识的行是不好的做法。

可能有几种情况需要PK，但这是规则中的例外情况。

Answer 3

如果清单表中的item_id是唯一的，我会说你可以将它用作标识符。主键通常用于唯一标识一条线，但在我看到的情况下，库存线标识没有用处。

编辑：正如其他人已经注意到的那样，通常如果你没有充分的理由使用主键，那么你将很好地查看你的表结构，看看你是否可以将它与另一个表合并，在这种情况下可能是物品表。我可以看到这不是一个选项的情况（例如你不能改变架构，只是添加新表），但值得一看。

Answer 4

  

我是否需要库存表的主键？

我们可以假设数据是关系型的吗？根据定义，关系没有重复的元组。 SQL允许表中的重复行。因此，为了确保在实践中没有重复的行，每个表应至少具有一个唯一约束。简而言之，您最好有充分的理由不对表中的每个候选键设置唯一约束。根据定义，零个或一个候选密钥可以被指定为“主要”，哪一个（如果有的话）应该接收这个名称是任意的。

  

我应该使用串行密钥还是复合密钥？

我认为这是一个错字。单列密钥称为“简单密钥”而不是“串行密钥”。根据您的描述，您的库存表在item_ID which is a simple key上有唯一的候选候选键。唯一可能的复合键是超级键，除非它被外键引用，否则不应使用唯一约束来约束。

  

表何时没有主键可以吗？

当使用UNIQUE约束约束所有候选键时，或者当表不打算保存关系数据时。

Answer 5

如果每个项目只有一个库存行 - 那么它将在同一个Item表中便宜得多（平均值 - CPU和IO），

如果不是 - 这取决于。它根本不是标准化数据

但据我了解这个问题，如果你坚持在两个表上 - 是的，最好在item_id字段上有一个索引