数据库 – 在“人员”主键和“产品”表的自然键之间进行确定

基本上，我将需要将来自多个供应商的产品数据组合成一个单一的数据库(当然比这更复杂)，其中有几个表需要大多数OLTP操作连接在一起。

我将坚持使用默认值，并使用自动递增整数作为主键，但是当一个供应商提供自己的“ProductiD”字段时，其余的不需要，我将不得不做很多手动映射到另一个表然后加载数据(因为我必须首先将其加载到Products表中，然后将ID和其他信息一起添加到其他表中)。

或者，我可以使用产品的SKU作为主要关键，因为SKU是唯一的产品，所有的供应商都在其数据Feed中提供SKU。如果我使用SKU作为PK，那么我可以轻松地加载数据源，因为所有内容都是基于SKU的，这是它在现实世界中的工作原理。然而，SKU是字母数字的，并且可能比基于整数的键稍微有效。

我应该看什么想法？

解决方法

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.

还有Surrogate Keys vs Natural Keys for Primary Key?

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!