Задать вопрос
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) добавлять поля.
  • Вопрос задан
  • 399 просмотров
Подписаться 1 Средний 2 комментария
Пригласить эксперта
Ответы на вопрос 1
@Akina
Сетевой и системный админ, SQL-программист.
Принципиально есть два варианта.

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

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

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

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

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

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

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

Похожие вопросы