Динамические атрибуты данных: как выбрать модель хранения

Динамические атрибуты нужны, когда у разных объектов один общий тип, но набор свойств меняется: товары, анкеты, карточки клиентов, характеристики оборудования, параметры услуг или отраслевые справочники. Главный выбор — не между модными форматами, а между гибкостью, проверяемостью, скоростью поиска, отчетностью и сопровождением.

EAV, JSONB и реляционная схема решают разные задачи. Ошибка — выбрать гибкую модель до того, как понятны фильтры, отчеты, обязательные поля, интеграции и правила качества данных.

• объекты имеют разные наборы свойств в зависимости от категории;
• атрибуты часто добавляются без релиза основной схемы;
• часть свойств нужна для фильтрации, поиска или аналитики;
• данные приходят из разных систем или внешних каталогов;
• нужно сохранить историю изменений или разные версии карточек.

• набор полей стабилен и хорошо описывается обычной таблицей;
• почти все атрибуты обязательны для всех объектов;
• нужны сложные отчеты по каждому полю, а модель качества еще не определена;
• гибкость нужна только потому, что требования не собраны;
• нет владельца справочников и правил валидации.

• типы объектов и категории, у которых разные свойства;
• список атрибутов, обязательность, тип данных и единицы измерения;
• какие поля участвуют в фильтрах, поиске, отчетах и интеграциях;
• кто может добавлять новые атрибуты и кто проверяет их качество;
• требования к истории изменений и версиям карточек;
• ограничения по производительности и объему данных;
• примеры 20-50 реальных карточек для проверки модели.

• Реляционная схема подходит для стабильных, обязательных и часто используемых полей.
• JSONB удобен для гибких свойств, когда часть атрибутов хранится вместе с объектом, но нужно продумать индексы и валидацию.
• EAV дает максимальную гибкость, но усложняет запросы, аналитику, контроль типов и сопровождение.
• Гибридная модель часто практичнее: ключевые поля в обычных колонках, изменяемые свойства — в JSONB или отдельной структуре.

• прятать в динамические атрибуты поля, которые на самом деле являются обязательной частью модели;
• не описать типы данных, единицы измерения и допустимые значения;
• выбрать EAV там, где нужны быстрые фильтры и понятная аналитика;
• не предусмотреть индексы, миграции и контроль качества;
• позволить пользователям создавать дублирующие или противоречивые атрибуты.

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