用作ID和PK的内容

Question

我有一个小问题。我想将有关产品的信息保存在sql数据库中。该产品具有唯一的12个部件号。

该产品将在数据库中链接多次。我应该使用什么作为唯一ID？零件编号？还是应该使用自动递增的id值？

什么是更好的性能明智的选择，而总的来说更好的选择是什么？

Answer 1

即使您确实具有在现实世界中有意义的唯一标识符（您的12位数字），也应该在表上使用“无意义”的替代键（自动递增，全局唯一ID等）。零件号）。

主要原因是，任何在现实世界中有意义的东西都可能会发生变化：公司合并时零件编号会发生变化，续订时注册编号也会发生变化，等等。最重要的是，总有可能发生错误-键入数字，然后稍后需要更正。

在发生这种情况时，更改不是主键的属性非常容易：这是对属性的简单更新。但是，更改主键变得非常困难，因为您可能有从其他表引用它的外键。仅这个原因就足以决定支持您表上的代理键。

Answer 2

我将使用自动生成的BigInteger / Integer（取决于您的需要）列作为PRIMARY KEY，并将零件号存储为UNIQUE（这将是候选密钥）。您将受益于将其存储在关系的表中所需的空间，并且更多的值可能会包含在单个页面中。如果您有机会需要更改产品编号，这种情况将是有益的。

但是，即使您只需要表中具有与产品表的外键关系的零件号，您仍需要额外的JOIN。通常，如果要显示部件号，还需要产品表本身的一些其他信息，这样就不会造成太大的伤害（因为对数据库进行了优化，可以快速执行联接操作）。

请确保在一个FOREIGN KEY列上创建索引，因此在这种情况下，所有表中都带有id_product之类的索引，以保持关系以加快匹配操作。

Answer 3

您的选择介于自然主键和替代主键之间。这里有bunch of trade-offs。

好消息是，性能不太可能成为其中之一-只要您可以使用索引进行搜索，自然键和代理键就可能执行相同的操作。

您存储的数据可能具有唯一的属性-SKU，社会保险号等-并且在创建架构时使用此属性似乎合乎逻辑。但是，这为您带来了各种边缘情况。

• 如果用户输入错误并想要更改数据怎么办？更改主键和外键是一个糟糕的主意。
• 如果生成您的自然密钥的系统存在错误并生成重复项怎么办？
• 如果生成自然键的系统被淘汰并且您获得的数据格式不兼容怎么办？重新构建模式以将主键/外键从整数转换为字符串是很可怕的。
• 如果您想与生成数据的多个系统集成，而他们对数据格式存在分歧，该怎么办？

我已经看到所有这些“假设”发生。

我会使用自动增量或GUID来获取代理密钥。