决定 Products 表的人工主键和自然键 [英] Deciding between an artificial primary key and a natural key for a Products table

问题描述

基本上，我需要将来自多个供应商的产品数据合并到一个数据库中(当然，它比这更复杂)，该数据库有多个表，大多数 OLTP 操作需要将这些表连接在一起.

Basically, I will need to combine product data from multiple vendors into a single database (it's more complex than that, of course) which has several tables that will need to be joined together for most OLTP operations.

我打算坚持使用默认值并使用自动递增的整数作为主键，但是虽然一个供应商提供了他们自己的ProductiD"字段，但其余的不提供，我将不得不进行大量手动映射到其他表，然后加载数据(因为我必须先将其加载到 Products 表中，然后取出 ID 并将其与我需要的其他信息一起添加到其他表中).

I was going to stick with the default and use an auto-incrementing integer as the primary key, but while one vendor supplies their own "ProductiD" field, the rest do not and I would have to do a lot of manual mapping to the other tables then to load the data (as I would have to first load it into the Products table, then pull the ID out and add that along with the other information I need to the other tables).

或者，我可以使用产品的 SKU 作为主键，因为 SKU 对于单个产品是唯一的，并且所有供应商都在其数据提要中提供 SKU.如果我使用 SKU 作为 PK，那么我可以轻松加载数据源，因为一切都基于 SKU，这就是它在现实世界中的工作方式.然而，SKU 是字母数字的，可能比基于整数的密钥效率稍低.

Alternatively, I could use the product's SKU as it's primary key since the SKU is unique for a single product, and all of the vendors supply a SKU in their data feeds. If I use the SKU as the PK then I could easily load the data feeds as everything is based off of the SKU, which is how it works in the real world. However the SKU is alphanumeric and will probably be slightly less efficient than an integer-based key.

有什么我应该考虑的想法吗?

Any ideas on which I should look at?

推荐答案

这是在 surrogate 之间的选择和自然主键.

恕我直言，总是喜欢代理主键.主键不应该有意义，因为意义可以改变.就连国名都可以改变，国家也可以存在和消失，更不用说产品了.绝对不建议更改主键，这可能发生在自然键上.

IMHO always favour surrogate primary keys. Primary keys shouldn't have meaning because that meaning can change. Even country names can change and countries can come into existence and disappear, let alone products. Changing primary keys is definitely not advised, which can happen with natural keys.

更多关于代理与主键:

所以代理键获胜对吗?好，让我们回顾一下，看看是否有任何自然键的缺点适用于代理键:

So surrogate keys win right? Well, let’s review and see if any of the con’s of natural key’s apply to surrogate keys:

• 缺点 1:主键大小——代理键一般没有问题具有索引大小，因为它们通常是int 类型的单列.那是尽可能小.
• 缺点 2:外键大小 - 他们没有外键或外键索引大小问题与 Con 1 相同的原因.
• 缺点 3:美学 - 嗯，这是一种旁观者的眼睛，但是他们当然不涉及写作与复合自然代码一样多的代码键.
• Con 4 &5:可选性适用性 – 代理键没有与人或事无关的问题想要或不能提供数据.
• 缺点 6:独特性 - 它们 100% 保证是独特的.那是一个解脱.
• 缺点 7:隐私 - 他们没有隐私问题不法分子得到它们.
• 缺点 8:意外的非规范化——你不能意外地非规范化非业务数据.
• Con 9:级联更新 - 代理键不会改变，所以不会担心如何将它们级联起来更新.
• Con 10:Varchar 加入速度 - 它们通常是 int 的，所以它们通常是尽快加入.

还有 主键的代理键还是自然键?

这篇关于决定 Products 表的人工主键和自然键的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！