Mysql - 我应该使用ID列吗？

我对最佳实践以及数据库引擎的工作原理有疑问。Mysql - 我应该使用ID列吗？

假设我创建一个名为Employee表，有以下栏目：

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

事情是..我看到很多数据库，它的所有表都有和称为ID的附加列，这是一个序列号。我应该把ID字段放在我的桌子上吗？我的意思是，它已经有一个主键被索引。序列号字段会使数据库工作得更快吗？如果我不使用它来链接或研究任何表格，我看不出它有什么用处。

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

谢谢！

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

这是错误的，对吧？

来源

2012-05-04 João Guilherme

“它已经被索引的主键”哪一个？你确定你可以使其中一个独特而不是空的吗？然后你不需要一个int主键 – Niranjan

顺序id的实际性能增益将取决于您如何使用表格。

如果您使用的是一些ORM框架，这些框架通常可以更好地使用整数类型的顺序ID [1]，通常使用顺序ID列来实现。
如果您不使用ORM框架，拥有您从不使用的id密钥和代理ss_id密钥，这实际上是您始终使用的密钥，这是毫无意义的。
如果您从其他数据库表（外键）引用employees，那么使用id列的效率可能更高，因为存储该整数在子表中消耗的空间会少于存储ss_id（我假设是CHAR或VARCHAR）无处不在。

在ss_id，假设它是一个社会安全号码（看起来像它会），有可能是连接到它，你应该关心的法律&隐私问题 - 我的回答假设你有正当的理由有社会安全号码在你的数据库中，并且你将被合法地允许使用&存储它们。

[1]这通常是由ORM框架依赖具有高度专用的缓存机制的事实来解释的，这种缓存机制专为典型的ORM使用量身定制 - 通常意味着拥有一个连续的主键，并让应用程序处理实际业务身份。事实上这与考虑非常类似于这些“外键”考虑有关。

来源

2012-05-04 14:22:20 Romain

SS_ID只是一个例子（很糟糕，对不起）。我这样问是因为我知道一些人只是要求我添加名为ID的列，如果我知道我们不会将它用于任何SQL查询，那么就是这样。他们只是认为它以某种方式帮助数据库的性能。这是错的，对吧？ –

那么，正如我在我的答案中所述，它有助于数据库性能*如果*它被用作跨表关系（外键）的一部分，或者*如果大多数SQL针对'id'列的表过滤器。 – Romain

@Romain：你能证明评论“这些通常有一个完整的类型的顺序ID更好地工作”？ – Cylindric

如果SS的意思是“社会保障”，我强烈建议不要使用，作为一个PK。自动递增的身份是要走的路。

使用内置业务逻辑的密钥是一个坏主意。许多人对提供SS信息很敏感。如果他们使用SS作为主键，您的应用可能会消除部分受众。 HIPPA等法律可能使您无法使用。

来源

2012-05-04 14:23:17 duffymo

+1建议不要存储社会安全号码。 – Romain

在存储之前，您应该对SS ID进行散列或模糊处理。所以你不能用它作为主键。这将是低效率和不安全的。 – Niranjan

@ngen它可以用这种方式进行加密，使其仍然可用作主键。由于这些ID通常很短，所以这样做的性能并不那么重要。 – Romain

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

来源

2012-05-04 14:26:46 jray

美国社会安全号码不充分识别。而银行肯定不要这样使用它们。不是每个人都有。错误导致重复。外国人没有他们。它们太脆弱了，不能用作数据库PK。

最重要的：的是死后resused

做一些研究：SSN as Primary Key

来源

2012-05-04 14:30:08 Cylindric

+1 - 我认为这个封印。 – duffymo

取决于用例。另外，不能只是“假设”他们指的是美国数字。因此，这个答案是IMO，非常不完整。 – Romain

也许不完整，但即使有什么似乎对我来说足够明确。其他国家将不得不面对同样的问题。 – duffymo