SQL中是否需要ID列？

Question

传统上我总是在SQL中使用ID列（主要是mysql和postgresql）。

但是我想知道如果每行中的其余列都是唯一的，那是否真的有必要。在我的最新项目中，我将“ID”列设置为我的主键，但是我从不调用它或以任何方式使用它，因为行中的数据使其独特并且对我来说更有用。

因此，如果SQL表中的每一行都是唯一的，它是否需要一个主键ID表，并且是否有一个性能变化？有多少？

谢谢！

编辑/附加信息： 让我问这个问题的具体例子是我用于多对多对多对表的表（如果我们在那时仍然称之为）它有4列（加上ID）每个代表一个外部表的ID，每行始终是数字和唯一的。只允许其中一列为空。

据我所知，对于普通表，ID主键列是一件非常好的事情。但是我觉得在这个特定的桌子上它只会浪费空间并减慢添加新行的速度。

Answer 1

如果您的数据集中确实有一些预先存在的列已经唯一标识了您的行 - 那么不需要额外的ID列。但主键必须唯一（在 ALL 情况下）并且不能为空（必须为非NULL）。

然而，在我20多年的数据库设计经验中，这几乎不是真的。大多数看似独特的“自然”ID都不是 - 最终。美国社会保障号码不保证是唯一的，大多数其他“自然”键最终几乎是唯一的 - 而这对于数据库系统来说还不够好。

因此，如果您的数据中确实有一个合适的，唯一的密钥 - 请使用它！但大多数情况下，只有一个代理ID可以保证在所有行中都是唯一的，这样更容易，更方便。

Answer 2

不要将逻辑模型与实现混淆。

逻辑模型显示可以成为主键的候选键（所有列）。

大。然而...

实际上，拥有一个多列主键有缺点：它很宽，在聚类等时不好。有很多信息在那里和右边的“相关”问题列表中

所以，你通常

• 添加代理键（ID列）
• 添加唯一约束以保持其他列的唯一性
• ID列将是群集密钥（每个表只能有一个）
• 您现在可以将任一键作为主键

主要的例外是连接2个ID列的链接或多对多表：不需要代理（除非你有一个脑卒中ORM）

修改，链接："What should I choose for my primary key?"

EDIT2

对于许多表：SQL: Do you need an auto-incremental primary key for Many-Many tables?

Answer 3

每个表中都应该有一列是唯一的。

... EDITED

这是数据库表设计的基础之一。它是行标识符 - 标识符标识正在对哪些行执行操作（更新/删除等）。依赖于“唯一”的列组合，例如（first_name，last_name，city），因为当两个John Smith存在时，您的密钥很快就会导致问题，或者当John Smith移动城市并且您发生碰撞时更糟。

在大多数情况下，最好使用一个保证唯一的人工密钥 - 比如自动增量整数。这就是他们如此受欢迎的原因 - 他们是需要的。通常，关键列简称为id，有时称为<tablename>_id。 （我更喜欢id）

如果可用的自然数据是唯一的并且存在于每一行（可能是人们的视网膜扫描数据），您可以使用它，但所有这些数据都不适用于每个 row。

理想情况下，您应该只有一个唯一列。也就是说，应该只有一个键。

Answer 4

对关键表使用ID意味着您可以根据需要更改内容，而无需重新指定内容

实施例。如果每一行都指向一个独特的用户，如果他/她更改了他的名字，让他们说已经在db中的 John Blblblbe ，会发生什么？然后，如果你的软件想要获取John Blblblbe的详细信息会发生什么呢？老约翰或者何浩改变了他的名字？好吧，如果机器人问题的答案是“没有什么特别的事情发生”那么，是的，你真的不需要“ID”专栏：]

重要：

此外，即使表没有任何索引键或具有多个唯一的

，当您正在查找确切的行时，使用带有数字的数字ID列会快得多

Answer 5

是的，您可以在记录（行）中使用许多属性（值）来创建唯一的记录。这将被称为复合主键。

然而，一般来说它会慢很多，因为主要指数的构建会更加昂贵。关系数据库管理系统（RDBMS）使用主索引不仅可以确定唯一性，还可以确定它们如何在磁盘上排序和构造记录。

一个递增值的简单主键通常是RDBMS管理的最高性能和最简单的解决方案。

Answer 6

如果你确定任何其他列都会为每一行都有唯一的数据，并且不会在任何时候都有NULL，那么就不需要单独的ID列来区分每一行，你可以制作表的现有列主键。

Answer 7

不，单属性键不是必需的，也不是代理键。密钥应具有数据完整性所需的尽可能多的属性：确保维持唯一性，准确表示话语领域并允许用户识别他们感兴趣的数据。如果您已经确定了合适的密钥，并且如果您没有找到任何真正的需要创建另一个密钥，那么向表中添加冗余属性和索引是没有意义的。

Answer 8

ID可以更有意义，例如，员工ID可以代表他所在的部门，他加入的年份等等。除此之外，RDBMS支持使用ID的批量操作。