在设计表时，我养成了一个习惯，即有一个唯一的列，并将其作为主键。这可以通过三种方式实现，具体取决于需求:
自动递增的标识整数列。
唯一标识符(GUID)
短字符(x)或整数(或其他相对较小的数字类型)列，可作为行标识符列
数字3将用于相当小的查找，主要是读取表，这些表可能有一个唯一的静态长度字符串代码，或一个数值，如年或其他数字。
在大多数情况下，所有其他表都有一个自动递增的整数或唯一标识符主键。
问题:-)
我最近开始使用一些数据库，这些数据库没有一致的行标识符，而且主键目前聚集在各个列之间。一些例子:
datetime /字符
datetime /整数
datetime / varchar
字符/ nvarchar / nvarchar
这有有效的理由吗?我总是为这些情况定义一个标识符或唯一标识符列。
此外，还有许多根本没有主键的表。如果有的话，合理的理由是什么?
我试图理解为什么桌子被设计成这样，对我来说，它似乎是一个很大的混乱，但也许有很好的理由。
第三个问题在某种程度上帮助我解析答案:在使用多个列组成复合主键的情况下，与代理/人工键相比，这种方法是否有特定的优势?我主要考虑的是性能、维护、管理等方面。
我将坦率地说明我对自然键的偏好——在可能的情况下使用它们，因为它们将使您的数据库管理工作更加容易。我在公司建立了一个标准，所有的表格都有以下列:
行ID (GUID)
创造者(字符串;有一个默认的当前用户名(SUSER_SNAME()在T-SQL))
创建(DateTime)
时间戳
行ID在每个表上都有一个唯一的键，并且在任何情况下都是每行自动生成的(并且权限阻止任何人编辑它)，并且合理地保证在所有表和数据库中是唯一的。如果任何ORM系统都需要一个ID密钥，那么可以使用这个密钥。
同时，如果可能的话，实际的PK是一个自然的关键。我的内部规则是这样的:
人-使用代理键，例如INT。如果它是内部的，那么Active Directory用户GUID是一个可以接受的选择
查找表(例如StatusCodes) -使用短的CHAR代码;它比int更容易记住，在许多情况下，纸张表格和用户也会使用它来简洁(例如，Status = "E"表示"过期"，"A"表示"已批准"，"NADIS"表示"样品中未检测到石棉")。
链接表- fk的组合(例如EventId, AttendeeId)
因此，理想情况下，您最终会得到一个自然的、人类可读的和难忘的PK，以及一个orm友好的每个表一个id的GUID。
警告:我维护的数据库倾向于100,000条记录，而不是数百万或数十亿条记录，所以如果您有使用大型系统的经验，这不利于我的建议，请随意忽略我!
以下是我拥有25年以上开发经验后得出的经验法则。
所有表都应该有一个单列主键auto
增量。
将它包含在任何意味着可更新的视图中
主键在应用程序上下文中不应该有任何意义。这意味着它不应该是SKU、帐号、员工id或对应用程序有意义的任何其他信息。它只是一个与实体相关联的唯一键。
主键由数据库用于优化目的，应用程序除了用于标识特定实体或与特定实体相关外，不应该使用主键。
始终使用单一值主键使得执行upsert非常简单。
Favor multiple indices on single columns over multi-column indices.
For example, if you have a two column key, favor creating an index on each column over creating a two column index. If we create a multi-column key on firstname + lastname, we can't do indexed lookups on lastname without providing a firstname as well. Having indices on both columns allows the optimizer to perform indexed lookups on either or both columns regardless of how they are expressed in your WHERE clause.
If your tables are massive, explore partitioning the table into segments based on the most prominent search criteria.
If you have a table that has a significant number of Id fields in it, consider removing all except the primary key to a single table which has an id (PK), an org_id (FK to original table) and an id_type column. Create indices for all columns on the new table and relate it to the original table. In this manner, you can now perform indexed lookups of any number of ids using only a single index.
