表中主键的最佳实践是什么？

Question

表中主键的最佳实践是什么？

在设计表格时，我养成了一种习惯，就是有一列是唯一的，我做主键。实现这一目标的方式有三种，视需要而定：

1. 自动递增的标识整数列。
2. 唯一标识符(GUID)
3. 一个短字符(X)或整数(或其他相对较小的数字类型)列，可用作行标识符列。

数字3将用于相当小的查找，大多数是读取表，这些表可能具有唯一的静态长度字符串代码，或数字值(如年份或其他数字)。

在大多数情况下，所有其他表都将具有自动递增整数或唯一标识符主键。

问题：-)

我最近已经开始使用没有一致行标识符的数据库，并且主键当前聚集在不同的列中。一些例子：

• 日期时间/字符
• 日期时间/整数
• 日期时间/varchar
• Char/nvarchar/nvarchar

这有正当理由吗？我会一直为这些情况定义标识或唯一标识符列。

此外，还有许多表根本没有主键。这样做的有效理由(如果有的话)是什么？

我试着去理解为什么桌子是按原来的设计的，对我来说，这似乎是一堆乱七八糟的东西，但也许这是有充分理由的。

第三个问题可以帮助我破译答案：在使用多个列组成复合主键的情况下，这种方法相对于代理/人工密钥有什么特殊的优势吗？我主要考虑的是性能、维护、管理等？

Answer 1

只是对一些经常被忽视的事情发表额外的评论。有时，不使用代理键在子表中有好处。假设我们有一个设计，允许您在一个数据库中运行多个公司(可能是托管解决方案，或者其他什么)。假设我们有这些表和列：Company:   CompanyId   (primary key)CostCenter:   CompanyId   (primary key, foreign key to Company)   CostCentre  (primary key)CostElement   CompanyId   (primary key, foreign key to Company)   CostElement (primary key)Invoice:   InvoiceId    (primary key)   CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)   CostCentre   (in foreign key to CostCentre)   CostElement  (in foreign key to CostElement)万一最后一点说不通的话，Invoice.CompanyId是两个外键的一部分，一个是CostCentre桌子和一张到成本要素桌子。主键是(InvoiceId, 公司).在这个模型中，不可能搞砸和引用成本要素从一个公司和一个CostCentre来自另一家公司。如果在成本要素和成本中心表它会是。搞砸的机会越少越好。