我对最佳实践以及数据库引擎的工作方式有疑问。
假设我创建了一个名为 Employee 的表，其中包含以下列：
问题是.. 我看到很多数据库，它的所有表都有一个名为 ID 的附加列，它是一个序列号。我应该在我的表中输入 ID 字段吗？我的意思是，它已经有一个要索引的主键。数据库使用顺序 ID 字段会更快吗？如果我不使用它来链接或研究任何表格，我看不出它有什么帮助。
它有帮助吗？如果是这样，为什么，数据库中发生了什么？
谢谢！
编辑 ----- 这只是一个愚蠢的例子。忘记 SS_ID，我知道选择主键有更好的方法。主要问题是因为我认识的一些人只是要求我添加名为 ID 的列，即使我知道我们不会将它用于任何 SQL 查询。他们只是认为它在某种程度上有助于数据库的性能，特别是因为 Microsoft Access 等一些数据库工具总是询问我们是否希望它添加这个新列。
这是错误的，对吧？
如果 SS 的意思是“社会保障”，我强烈建议不要将其用作 PK。自动递增的身份是要走的路。
使用内置业务逻辑的键是一个坏主意。很多人对提供 SS 信息很敏感。如果他们使用 SS 作为主键，您的应用程序可能会消除部分受众。像 HIPPA 这样的法律可能会让您无法使用。
具有顺序的实际性能增益id将在很大程度上取决于您如何使用该表。
id您从不使用的键和一个实际上是您一直使用的代理ss_id键是没有意义的。employees从其他数据库表（外键）引用，那么拥有一列可能会更有效id，因为存储该整数将比存储该整数在子表中消耗更少的空间ss_id（我假设是aCHAR或VARCHAR) 无处不在。在 上ss_id，假设它是一个社会安全号码（看起来应该是这样），可能存在您应该关心的法律和隐私问题 - 我的回答假设您确实有正当理由在您的数据库中拥有社会安全号码，并且您将在法律上被允许使用和存储它们。
[1] 这通常可以通过 ORM 框架依赖于具有高度专业化的缓存机制来解释，这些机制是为典型的 ORM 使用量身定制的 - 这通常意味着具有顺序id主键，并让应用程序处理实际的业务身份。这实际上与与这些“外键”考虑非常相似的考虑有关。
美国社会安全号码不足以识别。银行当然不会以这种方式使用它们。不是每个人都有一个。错误导致重复。外国人没有。它们太脆弱了，无法用作数据库 PK。
最重要的是：死后被重新使用
做一些研究：SSN 作为主键
更重要的（显然）是您有一个主键，只要您用于该主键的数据是唯一可识别的。在您的示例中，SSN 是唯一可识别的，这就是银行使用它们并且会起作用的原因。此示例的问题在于，您的 Employee ID 很可能被用作其他表中的外键，这意味着您正在获取个人信息（受法律保护）并将其散布到您的数据模型中。在这种情况下，使用 Auto Incremented 字段可能会做得更好。