冗余与聚合数据的性能

Question

我有几个代码/值/同义词列表（即 ICD 代码），其中包括多个有效期，聚合成版本（每年一个）。

所以现在我可以选择完全标准化的方法，结构如下：

VERSIONS(id INT PRIMARY KEY, name VARCHAR)
CODES(id INT PRIMARY KEY, code VARCHAR)
VALUES(id INT PRIMARY KEY, text VARCHAR)

CODEVALUES(code_id INT FOREIGN KEY CODES.id, 
    value_id INT FOREIGN KEY VALUES.id, 
    version_id INT FOREIGN KEY VERSIONS.id,
    synonym_nr INT) 
    with PK(code_id, value_id, version_id)

这样我最多可以有 14 条记录作为代码值，在过去 14 年中没有改变。对于 >14000 个代码，最多包含 20 个同义词，我最终在 CODEVALUES 中有 >2,000,000 条记录。

另一种方法是使用聚合表，例如

CODES(code VARCHAR, value VARCHAR, synonym_nr INT, min_version INT, max_version INT)

没有 FK。对于 code/value/synonym_nr 的每种组合，只有一条记录。

我知道规范化，但我正试图降低开发和管理的复杂性，因为我需要为每个 SQL 表（包括它的关系）提供一个 OR/M 实体，并且因为我有几十个这样的代码列表和因子 4因为班级人数很重要，

我想知道这些替代方案之间是否存在性能差异。

更新：

这些列表上的查询属于此类，即我查找具有特定版本的特定代码并希望该代码的默认值（synonym_nr = 0）。 由于这些查询通常是较大查询的一部分，因此每个查询事务可能会有 10k 到 100k 的此类代码查找。 使用方法#1，我至少有 2 个连接，并且 Db 必须为每个版本保存一个映射记录（代码/值的冗余）。虽然方法＃2定义了一个有效的版本范围，但必须通过

WHERE version >= min_version AND version <= max_version

所以它是连接和更多记录（索引效率？）与查询约束中的范围比较。会有显着的性能差异吗？

Answer 1

我完全同意@SeanLange 的这一点；

这将节省很少的前期时间，从长远来看会花费更多。

立即正确建模，以后您不必为其他人的查询进行故障排除。

考虑为您的版本、代码和值 PK 使用较小的数据类型，即 TINYINT 或 SMALLINT，而不是 INT（如果合适）。考虑为您的聚合表创建一个视图，如果需要，将您的 ORM 指向该视图。

或者，考虑不同的建模方法。如果更改率较低，则对版本号使用“from”和“to”方法可能会更紧凑。

根据您编写问题的方式，我猜您至少可以合理地胜任 SQL Server。尝试这两种方法并查看“典型”查询的查询计划，以了解 SQL Server 如何处理不同的方法。