SQL表中的ID字段：规则还是法律？
只是一个快速的数据库设计问题：你是否总是在每个表中使用ID字段，或者只是大多数？显然，您的大多数表都会受益，但是您是否曾经有过可能不想使用ID字段的表？
例如，我想添加向另一个表（foo）中的对象添加标签的功能。所以我有一个带有varchar字段的表FooTag来保存标记，还有一个fooID字段来引用foo中的行。我真的需要围绕一个基本上任意的ID字段创建聚簇索引吗？使用fooID和我的文本字段作为聚集索引会不会更有效率，因为我几乎总是会通过fooID进行搜索？另外，使用聚集索引中的文本可以保持数据的排序，使我在查询数据时更容易排序。缺点是插入需要更长时间，但不会被选择期间的增益所抵消，这种情况会更频繁地发生？
您对ID字段有何看法？可弯曲的规则，还是坚不可摧的法律？
编辑：我知道提供的示例未规范化。如果标记是项目的主要部分，有多个表被标记，以及其他“额外”，那么双表解决方案将是一个明确的答案。但是在这个最简单的情况下，归一化是否值得？它会节省一些空间，但在运行查询时需要额外的连接
回答 2
Stack Overflow用户
发布于 2019-05-21 09:30:59
正如其他人所说的，这是一个一般的，而不是绝对的规则，并且有很多例外(例如，带有复合键的表)。
在一些偶尔但有用的场合，您可能希望在已经具有(通常为复合)唯一标识符的表中创建人工ID。例如，在一个系统中，我创建了一个存储部件号的表；尽管部件编号是唯一的，但实际上它们可能会改变-我们添加了一个任意整数PartID。不太常见，但这是一个典型的现实世界的例子。
Stack Overflow用户
发布于 2019-05-21 10:29:16
聚簇索引不需要在主键或代理（标识列）上。
但是，您的设计未正常化。通常，对于标记，我使用两个表，一个标签表（带有代理键）和一个从标签到主题表的链接表，使用标签表中的代理键和主题表中的主键。这允许您的标签应用于不同的实体（照片，文章，员工，位置，产品等）。它允许您对多个表强制执行外键关系，还允许您发明标记层次结构和有关标记表的其他内容。
就这个设计的索引而言，它将取决于使用模式。
https://stackoverflow.com/questions/-100001180
复制相似问题