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

Question

表中主键的最佳实践是什么？在设计表格时，我养成了一种习惯，就是有一列是唯一的，我做主键。实现这一目标的方式有三种，视需要而定：自动递增的标识整数列。唯一标识符(GUID)一个短字符(X)或整数(或其他相对较小的数字类型)列，可用作行标识符列。数字3将用于相当小的查找，大多数是读取表，这些表可能具有唯一的静态长度字符串代码，或数字值(如年份或其他数字)。在大多数情况下，所有其他表都将具有自动递增整数或唯一标识符主键。问题：-)我最近已经开始使用没有一致行标识符的数据库，并且主键当前聚集在不同的列中。一些例子：日期时间/字符日期时间/整数日期时间/varcharChar/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来自另一家公司。如果在成本要素和成本中心表它会是。

搞砸的机会越少越好。