Как хранить динамические атрибуты в базе данных: EAV, JSONB и реляционная схема
Как выбрать модель хранения без лишних миграций, хаоса в атрибутах и проблем в аналитике
Почему динамические атрибуты становятся архитектурной проблемой
Пока набор свойств предсказуем, обычная реляционная схема остается самым понятным выбором. Сложности начинаются, когда атрибутов становится много, они зависят от типа объекта, а каждое новое поле тянет миграции, перепроверку интеграций и усложнение запросов.
Тогда выбирать приходится уже не колонку, а цену гибкости.
Что обычно ломается первым
- частые миграции под новые поля
- рост числа редко используемых колонок
- хаотичные custom fields
- усложнение фильтрации и отчетности
Почему это важно бизнесу
- архитектура влияет на аналитику
- модель данных влияет на интеграции
- ошибки в атрибутах бьют по поиску и фильтрам
- стоимость изменений быстро растет
Что такое EAV простыми словами
EAV или entity attribute value — это модель, в которой данные хранятся как отдельные записи вида сущность - атрибут - значение, а не как фиксированный набор колонок.
Она полезна там, где свойства часто меняются и сильно различаются между объектами. Это способ хранить данные внутри системы, а не универсальный ответ на все задачи модели данных.
Где EAV встречается чаще
- каталоги товаров
- custom fields
- metadata-heavy системы
- master data и справочники
Когда EAV выглядит полезным
- атрибутов много
- данные разрежены
- набор свойств часто меняется
- атрибутами нужно отдельно управлять
Что важно понимать
EAV— один из вариантов хранения- он не заменяет реляционную схему по умолчанию
- он не нужен там, где атрибуты уже стабильны
Где EAV действительно уместен, а где начинает мешать
EAV уместен там, где данные плохо живут в фиксированной схеме: в каталогах с зависимостью атрибутов от категории, в custom fields, metadata и master data, где сами атрибуты становятся объектом управления.
Трение начинается, когда нужны тяжелые фильтры, строгие ограничения типов и предсказуемая аналитика. Если атрибуты уже стабильны и важны для ключевых сценариев, им чаще подходят обычные поля.
Когда EAV оправдан
- много необязательных атрибутов
- высокая разреженность данных
- частое изменение набора свойств
- отдельное управление атрибутами
Где EAV дает трение
- сложные запросы и joins
- слабее контроль типов и ограничений
- дороже аналитика и BI
- хуже читаемость и сопровождение модели
Когда лучше выбрать JSONB, а когда оставить реляционную схему
JSONB часто становится компромиссом между жесткой схемой и полной универсальностью EAV. Он удобен там, где свойства динамические, но естественно живут внутри одного объекта.
Реляционная схема лучше там, где атрибуты стабильны, важны для отчетности, фильтрации и интеграционных контрактов. Во многих системах лучший ответ — смешанная модель: устойчивые поля живут в колонках, а менее стабильные свойства уходят в гибкий слой.
Когда выбирать JSONB
- свойства меняются, но принадлежат одному объекту
- нужна гибкость без постоянных миграций
- не нужен отдельный слой управления атрибутами
- объем аналитических требований ограничен
Когда выбирать реляционную схему
- атрибуты стабильны
- нужны строгие ограничения типов
- данные критичны для отчетности
- фильтрация и интеграции важнее гибкости
EAV vs JSONB vs реляционная схема: как сравнивать на практике
Главная ошибка здесь — спорить о технологии, а не о сценарии. Сравнивать стоит не названия подходов, а требования системы: насколько стабильны атрибуты, участвуют ли они в фильтрации и аналитике, нужен ли отдельный каталог атрибутов и как быстро меняется модель данных.
Реляционная схема
Лучше там, где важны стабильность, прозрачность, ограничения и предсказуемые запросы.
JSONB
Лучше там, где нужна контролируемая гибкость внутри одного объекта без отдельной модели атрибутов.
EAV
Оправдан там, где свойства разрежены, изменчивы и требуют собственного управляемого слоя метаданных.
Как выбрать модель под каталог, custom fields и metadata
Смотрите не на список функций, а на поведение данных в продукте. Для каталога важно, насколько глубоко атрибуты участвуют в фильтрах и поиске. Для custom fields — остаются ли они вторичным слоем или становятся частью ядра. Для metadata — нужна ли самим атрибутам отдельная жизнь.
Простой проверочный вопрос такой: что будет через год, когда свойств станет в несколько раз больше и бизнес захочет использовать их в отчетах, фильтрах и интеграциях?
Что проверить до выбора
- какие атрибуты действительно стабильны
- что участвует в фильтрации и аналитике
- нужен ли отдельный каталог атрибутов
- как быстро меняется набор свойств
Где чаще ошибаются
- выбирают EAV слишком рано
- используют JSONB как замену любой модели
- пытаются одной схемой решить все сценарии
- игнорируют требования отчетности и интеграций
Что это дает бизнесу
Правильный выбор модели данных снижает стоимость изменений, помогает удерживать качество данных и делает аналитику, поиск и интеграции более предсказуемыми.
Что получает команда
- меньше болезненных переделок
- лучше управляемость custom fields и metadata
- более честную архитектурную картину
Что получает бизнес
- предсказуемее развитие продукта
- меньше скрытого технического долга
- лучше качество данных для аналитики и поиска
FAQ
EAV и JSONB конкурируют?
Не совсем. JSONB хранит вариативные свойства внутри одного объекта, а EAV раскладывает их на отдельные факты сущность - атрибут - значение. Выбор зависит от того, нужна ли атрибутам собственная модель управления.
Когда не стоит начинать с EAV?
Когда атрибуты уже достаточно стабильны, важны для отчетности, часто участвуют в фильтрации и должны жить под жесткими ограничениями типов и целостности.
Можно ли сочетать реляционную схему, JSONB и EAV?
Да. Для многих систем это самый практичный путь: устойчивые поля остаются в реляционной модели, а менее стабильные свойства выносятся в дополнительный гибкий слой.
Когда смешанная модель лучше одного подхода?
Когда часть атрибутов уже стабильна и критична для отчетности, а часть остается изменчивой. В таких случаях устойчивые поля лучше держать в реляционной схеме, а гибкий слой выносить в JSONB или, реже, в EAV.
Что дальше
Если система уже упирается в постоянные миграции, тяжелые фильтры или хаотичные custom fields, проблему редко решает еще одно поле или индекс. Полезнее пересобрать саму модель атрибутов.
Практический следующий шаг — короткий архитектурный разбор: какие свойства действительно стабильны, что участвует в фильтрации и аналитике, где нужен отдельный каталог атрибутов, а где достаточно локальной вариативности. После этого обычно становится видно, где укреплять реляционное ядро, где уместен JSONB, а где EAV действительно оправдан.
24.04.2026 (обн. 16.05.2026)
ОКВЭД 62.01
Сведения об ИТ-деятельности© 2018–2026, ООО «РоботБулл Технолоджи» ИНН 9710065224