Head-Hunter
@Head-Hunter

Как лучше реализовать динамические поля?

Есть задача реализовать coхранение, вывод и фильтрацию данных заранее не известных, что-то вроде CRM системы
Например есть таблица "счета" с уже известными полями ссылками на справочники и т.д., также есть фильтрация этих данных ну и вывод в табличной форме, но суть в том что этих данных на каком то этапе развития станет мало и чтобы не пинать прогера и не ждать - нужно дать возможность админу поиграться с настройками и динамически добавить в эту сущность необходимые поля (типы которых будут заранее известны) указать мол нужно ли выводить в табличке это поле, фильтровать по нему, будет ли оно обязательно для заполнения или же нет.

так вот как сие чудное дело хранить в БД, на данном этапе планируется использовать mysql со следующей архитектурой таблиц:

---
data_account (id, ...) - сама таблица счетов

fields(id, type[int,string,date,directory], name, directory_name, is_required, use_on_table, use_on_filter, use_on_report, ...) - поля и типы

data_fields_map(data_type, field_id, sort, ...) - мапа связей сущности и полей в ней

data_fields_values(id, data_type, data_id, field_id, val_int, val_date, val_string, ...) - сохранка значений полей


- так вот насколько такой подход будет адекватным?!
Чувствую будет куча подводных камней в такой реализации - или быть может есть какие-то др решения может на лету в таблице (data_account) добавлять поля.
  • Вопрос задан
  • 281 просмотр
Пригласить эксперта
Ответы на вопрос 1
@Akina
Сетевой и системный админ, SQL-программист.
Принципиально есть два варианта.

Первый, уже указанный в комментарии от Ерлан Ибраев, EAV.

Второй - сериализация динамических параметров. JSON, XML и т.п.

В обоих вариантах по мере доработки параметры могут легко переноситься из динамического хранилища в постоянное. Также оба варианта допускают и множественные значения - в том числе в постоянном и временном хранилищах одновременно (что к тому же даёт потенцию одноступенчатой приоритезации).

Явный недостаток обоих способов - использование унифицированного типа данных в таблице (как минимум строковый, а данные запросто могут потребовать ещё и binary collation) вне зависимости от реального типа сохраняемых данных. Ещё один явный недостаток - необходимость выноса контроля целостности на клиентский уровень.

Что выбрать? а вот это уже зависит от того, что именно делается с данными.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы