Дизайн таблицы поиска JPA

Question

В моих руках дизайнерская дилемма, и я надеюсь, что вы, ребята, могли бы помочь мне с этим.

Проблема: У меня около 15 таблиц поиска для моего приложения, каждая с кодом иатрибуты значения.Мне было интересно, что будет лучшим подходом к дизайну для создания этих таблиц поиска.

У меня в голове было несколько решений

1. Наличие одного абстрактного суперкласса (скажем, BaseLookupTable ) с кодом и Значение свойств, а затем приступить к созданию 15 специализированных классов поиска, расширяющих этот класс.или
2. Создайте тип enum для каждой из 15 таблиц поиска.

Если вы, ребята, могли бы помочь мне выбрать решение (даже не упомянутое мной) вместе с причинами для этогобудет очень признателен.

Ура, Сумант

Answer 1

Я бы выбрал вариант 1, поскольку в вашем коде зафиксированы перечисления.Если вы хотите добавить опцию в таблицу поиска, вам нужно только вставить ее в вашу базу данных.С перечислениями вам нужно перекомпилировать ваше приложение.

Answer 2

Я не думаю, что обычный базовый класс JPA имеет такое большое применение.

Предполагая, что вы не моделируете общий интерфейс ключ / значение, почему бы не кодировать конкретную семантику в имена столбцов справочной таблицы, например, роль_имя, код_состояния и т. д .?

Не уверен, используете ли вы также DB ENUM, например, ENUMs MySQL . Я предполагаю это для следующего параграфа (это специфично для MySQL). Другие СУБД, такие как PostgreSQL, имеют не избыточные ENUM, поэтому следующее может не относиться к вашей ситуации:

MySQL ENUM нельзя применять в любой ситуации. Вы должны использовать MySQL ENUM, если значения поиска однозначные и в основном ссылаются только на одну таблицу / сущность. Моя политика заключается в добавлении отдельной справочной таблицы, если на значения ссылаются более чем из одной другой таблицы или для справочной таблицы требуется более одного атрибута. Обратите внимание, что использование того же определения ENUM в БД добавляет избыточность. Использование MySQL ENUMs экономит вам таблицу, объединение и некоторые отношения. Помните, что значения DB ENUM должны быть как можно более статичными. Если они должны измениться, используйте таблицу поиска снова.

Честно говоря, это не простая тема, и мне пришлось поделиться своим мнением по этой теме, хотя это включает в себя особенности MySQL.