基本上，我将需要将来自多个供应商的产品数据组合成一个单一的数据库(当然比这更复杂)，其中有几个表需要大多数OLTP操作连接在一起。
我将坚持使用默认值，并使用自动递增整数作为主键，但是当一个供应商提供自己的“ProductiD”字段时，其余的不需要，我将不得不做很多手动映射到另一个表然后加载数据(因为我必须首先将其加载到Products表中，然后将ID和其他信息一起添加到其他表中)。
或者，我可以使用产品的SKU作为主要关键，因为SKU是唯一的产品，所有的供应商都在其数据Feed中提供SKU。如果我使用SKU作为PK，那么我可以轻松地加载数据源，因为所有内容都是基于SKU的，这是它在现实世界中的工作原理。然而，SKU是字母数字的，并且可能比基于整数的键稍微有效。
我应该看什么想法？
解决方法
这是
surrogate and natural primary keys之间的选择。
IMHO总是喜欢替代主键。主键不应该有意义，因为这个意思可以改变。甚至国名也可以改变，国家也可以生存和消失，更不用说产品了。绝对不建议更改主键，这可以通过自然键进行。
更多关于surrogate vs primary 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:
- Con 1: Primary key size – Surrogate keys generally don’t have problems
with index size since they’re usually
a single column of type int. That’s
about as small as it gets.- Con 2: Foreign key size – They don’t have foreign key or foreign
index size problems either for the
same reason as Con 1.- Con 3: Asthetics – Well,it’s an eye of the beholder type thing,but
they certainly don’t involve writing
as much code as with compound natural
keys.- Con 4 & 5: Optionality & Applicability – Surrogate keys have no
problems with people or things not
wanting to or not being able to
provide the data.- Con 6: Uniqueness – They are 100% guaranteed to be unique. That’s a
relief.- Con 7: Privacy – They have no privacy concerns should an
unscrupulous person obtain them.- Con 8: Accidental Denormalization – You can’t accidentally denormalize
non-business data.- Con 9: Cascading Updates – Surrogate keys don’t change,so no
worries about how to cascade them on
update.- Con 10: Varchar join speed – They’re generally int’s,so they’re generally
as fast to join over as you can get.
