基本上，我需要将来自多个供应商的产品数据组合到单个数据库中(当然，这要复杂得多)，该数据库具有多个表，大多数OLTP操作需要将这些表联接在一起.
我打算坚持默认设置并使用一个自动递增的整数作为主键，但是虽然有一家供应商提供了他们自己的"ProductID"字段，但是睡觉没有提供，所以我必须手动映射到其他表，然后加载数据(因为我必须首先将其加载到Products表中，然后取出ID并将其与我需要的其他信息一起添加到其他表中).
或者，我也可以使用产品的SKU作为其主键，因为SKU对于单个产品是唯一的，并且所有供应商都在其数据提要中提供一个SKU.如果我使用SKU作为PK，那么我可以很容易地加载数据馈送，因为一切都基于SKU，这就是它在现实世界中的工作方式.但是，SKU是字母数字的，可能会比基于整数的密钥效率稍低.
有什么我应该看看的 idea 吗？
这是surrogate and natural primary keys个人之间的 Select .
IMHO总是偏爱代理主键.主键不应该有意义，因为它的意义可能会改变.甚至国家名称都可以改变，国家可以存在和消失，更不用说产品了.绝对不建议更改主键，自然键可能会发生这种情况.
关于surrogate vs primary keys的更多信息:
代理密钥赢了，对吗？好
- 缺点1:主键大小-代理键通常没有问题
- 缺点2:外键大小-它们没有外键或外键 的索引大小问题 原因与条件1相同.
- 缺点3:哮喘患者——嗯，这是一种旁观者式的东西，但是
- Con 4&；5:可选性和适用性-代理键没有 人或事的问题不是 想要还是不能 提供数据.
- 缺点6:独特性——它们100%保证是独一无二的.这是个好主意
- Con 7:隐私——他们没有隐私问题，应该
- 会议8:意外的非正规化-你不能意外地反正规化 非业务数据.
- Con 9:层叠更新-代理键不会更改，因此不会更改
- 缺点10:VtererJOIN速度-它们通常是int类型的，所以它们通常是 以最快的速度加入进来.