Является ли OTLT (One True Lookup Table) хорошим подходом? - PullRequest
Новая
       138

Является ли OTLT (One True Lookup Table) хорошим подходом?

0 голосов
/ 14 июля 2020

Каждый раз, когда я вижу OTLT (One True Lookup Table), он же MUCK (Massively Unified Code-Key), шаблон, упоминаемый где-либо, он описывается как чистое зло и одна из худших ошибок дизайна вы можете сделать . Однако в настоящее время я работаю над проектом, в котором используется этот шаблон и кажется подходящим. Ниже представлена ​​структура таблицы (немного упрощенная): 

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 в отдельной таблице. В этом случае для этого потребовалось бы 3 таблицы на одну LOOKUP_TYPE запись, что более чем удвоит количество таблиц в базе данных и, в свою очередь, сильно раздувает код доступа к данным / конфигурацию приложения.

Это действительно практично? Должен ли я придавать такое большое значение способности базы данных универсально обеспечивать ссылочную целостность?

Есть ли альтернатива, которая помогает поддерживать ссылочную целостность без создания огромного количества таблиц?

...