Question

我有几个代码/值/同义词列表（i.a.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年中没有变化。对于包含最多20个同义词的＆gt; 14000个代码，我最终在CODEVALUES中使用＆gt; 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指向视图。

或者，考虑一种不同的建模方法。如果变化率很低，那么使用＆＃39;来自＆＃39;和＆＃39;到＆＃39;版本号的方法可能更紧凑。

根据您撰写问题的方式，我猜测您至少可以合理地使用SQL Server。尝试这两种方法，然后查看典型的＆＃39;的查询计划。查询SQL Server如何处理不同的方法。

冗余与聚合数据的性能

1 个答案: