Mysql - 我应该使用ID列吗？

Question

我对最佳做法以及数据库引擎的工作方式存有疑问。

假设我创建了一个名为Employee的表，其中包含以下列：

• SS ID（主键）
• 名称
• 性
• 年龄

事情是..我看到很多数据库都有它的所有表，而aditional列叫做ID，这是一个序列号。我应该把ID字段放在我的桌子上吗？我的意思是，它已经有一个要编制索引的主键。使用顺序ID字段，数据库是否会更快地运行？我不知道如果我不使用它来链接或研究任何表格，它会有什么帮助。

有帮助吗？如果是这样，为什么，数据库中会发生什么？

谢谢！

编辑----- 这只是一个愚蠢的例子。忘记SS_ID，我知道有更好的方法来选择主键。主要的主题是因为我认识的一些人只是要求我添加名为ID的列，即使我知道我们不会将它用于任何SQL查询。他们只是认为它以某种方式帮助数据库的性能，特别是因为像Microsoft Access这样的数据库工具总是会询问我们是否希望它添加这个新列。

这是错的，对吧？

Answer 1

如果SS意味着“社会保障”，我强烈建议不要将其用作PK。自动递增的身份是可行的方法。

使用内置业务逻辑的密钥是个坏主意。许多人对提供SS信息非常敏感。如果他们使用SS作为主键，您的应用可能会消除部分受众群体。像HIPPA这样的法律可以让你无法使用。

Answer 2

顺序id的实际性能提升将取决于您如何使用该表。

• 如果您正在使用某些ORM框架，这些通常可以更好地使用整数类型的顺序ID [1]，这通常使用顺序ID列来实现。
• 如果您不使用ORM框架，那么拥有一个永远不会使用的id密钥和一个代理ss_id密钥，这是您经常使用的密钥。
• 如果您从其他数据库表（外键）引用employees，那么拥有id列可能会更有效，因为存储该整数将消耗更少子表中的空格，而不是存储ss_id（我假设是CHAR或VARCHAR）。

在ss_id上，假设它是一个社会安全号码（看起来会是这样），可能会有合法的＆amp;您应该关注的隐私问题 - 我的答案假设您确实有正当理由在您的数据库中包含社会安全号码，并且您将在法律上允许使用＆amp;存储它们。

[1]这通常可以解释为ORM框架依赖于高度专业化的缓存机制，这些机制是针对典型的ORM使用而定制的 - 这通常意味着具有顺序id主键，并让应用程序处理具有实际的商业身份。事实上，这与“外键”考虑因素非常相似。

Answer 3

美国社会安全号码不足以识别。银行当然不以这种方式使用它们。不是每个人都有一个。错误导致重复。外国人没有。它们太脆弱而无法用作数据库PK。

最重要的是：死后重复使用

做一些研究：SSN as Primary Key

Answer 4

更重要的（显然）是你有一个主键，只要你用于该主键的数据是唯一可识别的。在您的示例中，SSN是唯一可识别的，这就是银行使用它们并且可以工作的原因。此示例的问题在于，您的员工ID可能会在其他表中用作外键，这意味着您将获取个人信息（受法律保护）并将其喷洒到您的数据模型中。在这种情况下，您可以使用自动增量字段做得更好。