Подход к работе со справочниками в кастомных таблицах
При работе с кастомными таблицами нередко возникает задача организации редактируемых полей с предопределёнными значениями. Наиболее удобный и понятный способ реализации — выпадающий список с возможностью выбора значения. Однако реализация такого механизма с учётом масштабируемости и поддержки требует отдельного подхода.
Проблема традиционного подхода
Распространённая практика — создавать отдельные справочные таблицы для каждого поля, значения которого должны быть выбраны из фиксированного набора. Эти таблицы связываются с основными таблицами через relation-поля.
Недостатки этого подхода:
- Увеличение количества служебных таблиц
- Повышенная сложность администрирования
- Дублирование структуры и логики
- Низкая гибкость при масштабировании
Универсальный справочник значений
Альтернативный подход — использование одной универсальной справочной таблицы, содержащей все возможные значения для всех полей, сгруппированные по принадлежности к конкретным таблицам и полям.
Структура таблицы enum_values
На рисунке представлена конфигурация таблицы enum_values. Она содержит следующие поля:
- id — уникальный идентификатор (тип AUTOINCREMENT)
- key — внутренний код значения
- value — отображаемое значение
- table_code — код таблицы, к которой относится значение
- field_code — код поля внутри таблицы
Применение на практике
При настройке relation-поля в интерфейсе таблицы необходимо задать дополнительные условия связи, чтобы фильтровать значения в выпадающем списке.
Пример:
Таким образом, пользователь увидит только те значения, которые относятся к нужной таблице и полю.
Преимущества подхода
- Минимизация структуры: вместо множества однотипных таблиц — одна.
- Гибкость: добавление новых справочников — без изменения модели данных.
- Чистота интерфейса: в выпадающем списке только актуальные значения, без пересечений.
- Простота поддержки: централизованное редактирование справочных значений.
Заключение
Предложенный подход обеспечивает централизованное управление справочными значениями и снижает издержки на поддержку. В условиях постоянно расширяющейся модели данных он позволяет избежать роста количества сущностей и упростить логику отображения на интерфейсном уровне.