database - 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提供第 3 方与内部类型和值之间的映射。LOOKUP_VALUE_TRANS并且INTEGRATION_VALUE每个都有与基表相似数量的记录。

我已经看到建议的 OTLT 的“解决方案”是将每个存储LOOKUP_TYPE在它自己的表中。在这种情况下，每条记录需要 3 个表LOOKUP_TYPE，这将使数据库中的表数量增加一倍以上，进而导致应用程序的数据访问代码/配置大量膨胀。

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

有没有一种替代方法可以在不创建大量表的情况下帮助保持参照完整性？

标签： databasedatabase-designrelational-database