OTLT（一个真实查找表）是一种好方法吗？

Question

每当我看到 OTLT（一个真正的查找表），又名 MUCK（大规模统一代码密钥），任何地方提到的模式时，它都会被描述为“纯粹的邪恶”和“你可能犯的最糟糕的设计错误之一”。然而，我目前正在开发一个项目，其中使用了这种模式并且看起来很合适。下面是表结构（稍微简化）：

create table LOOKUP_TYPE
(
    CODE         nvarchar(20) PK,
)

create table LOOKUP_VALUE
(
    ID           int PK identity,
    TYPE_CODE    nvarchar(20) references LOOKUP_TYPE(CODE),
    VALUE        nvarchar(255)
)

这些表包含

数百种

类型。此外，还有两个“支持”表：

LOOKUP_VALUE_TRANS

，用于保存翻译；INTEGRATION_VALUE，用于提供第三方与内部类型和值之间的映射。

LOOKUP_VALUE_TRANS

和

INTEGRATION_VALUE

各自具有与基表相似的记录数。我见过建议的 OTLT“解决方案”是将每个

LOOKUP_TYPE

存储在它自己的表中。在这种情况下，每个

LOOKUP_TYPE

记录需要 3 个表，这将使数据库中的表数量增加一倍以上，进而导致应用程序的数据访问代码/配置大量膨胀。

真的实用吗？我应该如此重视数据库普遍实施引用完整性的能力吗？

有没有一种替代方法可以帮助维护引用完整性而不创建大量表？

Microsoft Dynamics365 正在使用此模式（StringMap）。我认为这没关系，因为许多成功的商业软件都在使用这种模式。

Answer 1