SQL表中的ID字段:规则还是法律？
快速数据库设计问题:您总是在每个表中使用ID字段，还是只在大多数表中使用ID字段？显然，大多数表都会从中受益，但是有没有您可能不想使用ID字段的表呢？
例如，我想添加向另一个表(foo)中的对象添加标记的功能。所以我有一个表FooTag，它有一个varchar字段用来保存标记，一个fooID字段用来引用foo中的行。我真的需要在一个基本上任意的ID字段周围创建一个聚集索引吗？使用fooID和我的文本字段作为聚集索引不是更有效吗?因为我几乎总是使用fooID进行搜索。此外，在聚集索引中使用我的文本将保持数据的排序，当我必须查询我的数据时，排序变得更容易。缺点是插入会花费更长的时间，但这不是会被选择过程中的收益所抵消，这会发生得更频繁吗？
你对ID字段有什么看法？可弯曲的规则，还是牢不可破的法律？
编辑:我知道提供的示例没有规范化。如果标记是项目的主要部分，多个表被标记，以及其他‘额外’，两个表的解决方案将是一个明确的答案。然而，在这个最简单的情况下，规范化是否值得呢？这将节省一些空间，但在运行查询时需要额外的连接
回答 7
Stack Overflow用户
发布于 2009-01-13 15:58:45
就像在很多编程中一样:法律规则，而不是。
例外证明:一些包含两列的表的存在只是为了形成其他更有意义的表之间的关系。
Stack Overflow用户
发布于 2009-01-13 16:04:03
如果您正在制作连接两个或更多其他表的表，并且您需要的唯一字段是双PK/FK，那么我不知道为什么您还需要ID列。
ID列通常非常有用，但这并不意味着您应该在每个场合都使用它们。
Stack Overflow用户
发布于 2009-01-13 16:20:55
正如其他人所说，这是一个通用的规则，而不是绝对的规则，也有很多例外(例如带有组合键的表)。
在某些偶尔但有用的情况下，您可能希望在已经具有唯一标识符(通常是复合标识符)的表中创建一个人工ID。例如，在一个系统中，我创建了一个表来存储零件号；尽管零件号是唯一的，但它们实际上可能会改变-我们添加了一个任意整数PartID。这并不常见，但这是一个典型的真实世界的例子。
https://stackoverflow.com/questions/439507
复制相似问题
腾讯云开发者
