我避免使用自然键的原因很简单——人为错误。虽然通常可以使用自然的唯一标识符(SSN、VIN、Account Number等)，但它们需要人工正确输入。如果您使用ssn作为主键，有人在数据输入期间调换了几个数字，并且没有立即发现错误，那么您将面临更改主键的问题。

我的主键都是由数据库程序在后台处理的，用户永远不会知道它们。

如果有天然钥匙，通常是最好的。因此，如果datetime/char唯一地标识了行，并且这两部分对行都有意义，那就太好了。

如果只有datetime是有意义的，并且只是附加了char以使其唯一，那么您不妨使用一个identify字段。

您应该使用由多个字段组成的“复合”或“复合”主键。

这是一个完全可以接受的解决方案，点击这里了解更多信息:)

我寻找自然主键，并尽可能地使用它们。

如果找不到自然的键，我更喜欢GUID而不是INT++，因为SQL Server使用树，总是在树的末尾添加键是不好的。

在多对多耦合的表上，我使用外键的复合主键。

因为我很幸运使用SQL Server，我可以用分析器和查询分析器研究执行计划和统计数据，并很容易地发现我的键是如何执行的。

表应该一直有一个主键。如果没有，它应该是一个自动递增字段。

有时人们会省略主键，因为他们要传输大量数据，这可能会减慢(取决于数据库)进程。但是，它应该加在它之后。

一些关于链接表的评论，这是正确的，这是一个例外，但是字段应该是FK以保持完整性，并且在某些情况下，如果链接中的重复没有被授权，这些字段也可以是主键…但是要保持简单的形式，因为异常在编程中经常出现，所以应该提供主键来保持数据的完整性。

我总是使用自动编号或标识字段。

我曾经为一个客户工作，他使用SSN作为主键，然后由于HIPAA法规被迫更改为“MemberID”，这在更新相关表中的外键时引起了大量问题。坚持一致的标识列标准帮助我在所有项目中避免了类似的问题。