使用项目特定的前缀和自动编号为主键？

今天早上我们开了一个会议,讨论如何将我们的ID存储在我们正在制作的数据库中的某些资产中,这些描述产生了一些热量,所以我决定咨询SO的专家.

我相信我们应该拥有的表格结构(简短版本)如下所示:

例1)

AssetId - int(32) - 主键

类型 - 字符串

所以一些示例数据是这样的:

==AssetId======Type===
  12345        "Manhole"
  155415       "Pit"

等等

团队的另一名成员建议这样的事情:

例2)

AssetId - 字符串 - 主键

类型 - 字符串

所以一些示例数据是这样的:

==AssetId======Type===
  "MH12345"    "Manhole"
  "P155415"    "Pit"

我们制作该类型的简短版本并将其附加到ID的前面并将其存储在数据库中.我已经看到一些资产数据库这样做,从来没有真正的这种方法.

我从来没有真正喜欢使用字符串作为ID来排序的原因.当你已经拥有资产商店的类型时,我也觉得存储无用的信息只是为了它.

你会采取什么方法？为什么？使用方法1超过2有什么好处？

编辑:是的我将使用AUTO_INCREMENT方法1.

1> Riho..：

---

通常,经验法则是永远不要在主键中使用有意义的信息(如社会安全号码或条形码).只是简单的自动增量整数.然而,数据似乎是不变的 - 它可能会在某一时刻发生变化(新立法到来并且所有SSN都会重新计算).

---

是! 在过去的3家公司中,由于一些白痴选择了"自然"的钥匙,因此造成了很大的痛苦.UPC可以回收利用; 不是每个人都有SSN; 人们搞砸了创建SKU.你存储它,你可以UNIQUE它,但PK是你的关系密码.你不暴露它.

2> cletus..：

---

这是代理和自然密钥之间的决定,第一个是代理(或"技术"),第二个是自然的.

我得出结论,你应该总是使用代理键.如果您使用自然键,那些可能会更改,更新主键/外键通常不是一个好主意.