【问题标题】:How best to update row where composite primary key values change如何最好地更新复合主键值更改的行
【发布时间】:2022-12-20 08:53:00
【问题描述】:

我最近开始在一家新公司工作,有一小群开发人员在同一个地方工作了 20 多年。所有人都是非常优秀、聪明和有才华的人,但我遇到了我发现非常不标准的做法,我在过去六年从事开发运营和开发的工作中很少遇到过这种做法20年。我远非数据库专家,所以我想知道执行以下操作的最佳方法。

我们有许多表,其中我们有包含多个条目的复合键。在某些情况下,多达 6 个值构成一个表的主键,该表不是超大,可能有几千个条目,并且访问频率不高。

在我看来,更好的解决方案是使用一个主键,它是一个自动递增的 ID 字段,为了确保现在用作主键的六个不同字段的组合是唯一的,您可以创建具有唯一约束的索引。性能可能不会那么好,但代码复杂性会大大降低。

有人告诉我,使主键如此复杂是必要的,因为主键是表上唯一的聚集索引,这可以提高性能。我能理解这会有什么帮助,但这对性能提升有那么大的帮助吗?这似乎是一种过早的优化情况。

使用复合主键是实际的常见做法吗?我知道如果你有一个非常大的表,有数千个条目,并且经常被击中,那么即使是一个小的性能增强也值得增加我所看到的复杂性。

似乎拥有一个由可以更新/更改的值组成的主键只是在自找麻烦。如果其他表正在引用它不会导致问题吗?

我认为,这主要是为了在以后添加新表,因为我认为更改现有表的结构可能过于剧烈,他们无法接受。但我想知道我是否在试图反对这种做法之前越界了。

【问题讨论】:

  • “......因为主键是唯一的聚集索引......” - 这取决于特定的数据库以及表创建参数。你使用什么数据库?
  • “……好像有点过早优化的情况。” - 绝对地。对于无意义的 2k 行表。如果您正在谈论一个需求量很大的 200 万行表,也许吧。对于 20 亿行,这是肯定的。
  • 有问题的是 DB2。但我认为这种做法已扩展到数据被复制到的 MSSQL 数据库。但我不完全确定那部分。还是有点新。
  • “...由可以更新/更改的值组成的主键只是自找麻烦。” --更新PK在理论上没有错。然而,它的设计决定不应该掉以轻心。大多数时候更新是出于错误的原因。

标签: sql database primary-key composite-primary-key


【解决方案1】:

通常使用许多列来形成一个 PRIMARY KEY 是我在数据库审计中经常发现的最糟糕的做法。事实上,它曾用于 50 年代的分层数据库模型中……由于性能不佳而被删除!

数据库关系模型说键可以是任何列或一组列,但数据库专家和从业者都证明,为了保证可扩展性,最好的性能方法是只有一个列的键,并且数据类型是:

  • 字节最短
  • 值最大
  • 具有语义值
  • 顺序单调

假设所有这些考虑因素的唯一方法是拥有一个具有自动增量数据类型(例如 IDENTITY 或 SEQUENCE)的 PRIMARY KEY。

其他所有数据类型或方法都有一些额外的开销或性能不佳。

在具有复合列的 PK 的情况下,优化器的统计信息仅对键的第一列是准确的。多列组合的统计不存在任何准确的方式(严格相等情况下键的所有值的完整集合当然这总是等于1)并进行优化器得到全局选择性的平均值或最差,计算相关基数。在这两种情况下,执行计划的质量都会很差,有时甚至是灾难性的……

对于 MS SQL Server 聚簇索引是 PK 的最佳选择,前提是严格应用我写的所有规范。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-03-18
    • 1970-01-01
    • 2020-09-01
    • 1970-01-01
    • 1970-01-01
    • 2012-08-23
    相关资源
    最近更新 更多