【发布时间】:2022-12-20 08:53:00
【问题描述】:
我最近开始在一家新公司工作,有一小群开发人员在同一个地方工作了 20 多年。所有人都是非常优秀、聪明和有才华的人,但我遇到了我发现非常不标准的做法,我在过去六年从事开发运营和开发的工作中很少遇到过这种做法20年。我远非数据库专家,所以我想知道执行以下操作的最佳方法。
我们有许多表,其中我们有包含多个条目的复合键。在某些情况下,多达 6 个值构成一个表的主键,该表不是超大,可能有几千个条目,并且访问频率不高。
在我看来,更好的解决方案是使用一个主键,它是一个自动递增的 ID 字段,为了确保现在用作主键的六个不同字段的组合是唯一的,您可以创建具有唯一约束的索引。性能可能不会那么好,但代码复杂性会大大降低。
有人告诉我,使主键如此复杂是必要的,因为主键是表上唯一的聚集索引,这可以提高性能。我能理解这会有什么帮助,但这对性能提升有那么大的帮助吗?这似乎是一种过早的优化情况。
使用复合主键是实际的常见做法吗?我知道如果你有一个非常大的表,有数千个条目,并且经常被击中,那么即使是一个小的性能增强也值得增加我所看到的复杂性。
似乎拥有一个由可以更新/更改的值组成的主键只是在自找麻烦。如果其他表正在引用它不会导致问题吗?
我认为,这主要是为了在以后添加新表,因为我认为更改现有表的结构可能过于剧烈,他们无法接受。但我想知道我是否在试图反对这种做法之前越界了。
【问题讨论】:
-
“......因为主键是唯一的聚集索引......” - 这取决于特定的数据库以及表创建参数。你使用什么数据库?
-
“……好像有点过早优化的情况。” - 绝对地。对于无意义的 2k 行表。如果您正在谈论一个需求量很大的 200 万行表,也许吧。对于 20 亿行,这是肯定的。
-
有问题的是 DB2。但我认为这种做法已扩展到数据被复制到的 MSSQL 数据库。但我不完全确定那部分。还是有点新。
-
“...由可以更新/更改的值组成的主键只是自找麻烦。” --更新PK在理论上没有错。然而,它的设计决定不应该掉以轻心。大多数时候更新是出于错误的原因。
标签: sql database primary-key composite-primary-key