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

Динамические атрибуты данных — это свойства, состав которых может различаться у объектов одного класса или расширяться при эксплуатации системы. Например, у разных видов оборудования нужны разные технические характеристики. Изменение значения обычного поля само по себе не делает его динамическим: речь именно о составе и описании свойств.

EAV — модель «сущность — атрибут — значение»: свойства объекта хранятся отдельными записями со ссылками на объект и определение атрибута. Ее можно сочетать с обычными колонками: основные поля остаются в таблице объекта, изменяемые характеристики выносятся в расширяемую часть.

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

В обычной таблице свойство объекта часто представлено колонкой: например, inventory_number для инвентарного номера. В EAV описание свойства и его значения становятся данными. Новый атрибут можно зарегистрировать в справочнике и связать с объектами без добавления соответствующей колонки в основную таблицу.

Сущность, атрибут и значение

• Сущность (Entity) — конкретный объект, например единица оборудования с идентификатором 17.
• Атрибут (Attribute) — определение свойства: код, название, тип, единица измерения, применимость и правила заполнения.
• Значение (Value) — факт о конкретном объекте: для оборудования 17 атрибут «мощность» равен 2,2 кВт.

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

В документации CUBA ↗ динамические атрибуты прямо описаны как реализация EAV с отдельными определениями и значениями. В статье рассматривается общий принцип, без привязки к этой платформе.

Учебный пример с характеристиками оборудования

Рассмотрим учебный каталог оборудования. Объект 17 — насос, объект 18 — емкость. Названия, идентификаторы и числовые значения условны; пример показывает устройство модели, а не результат внедрения.

У обоих объектов есть идентификатор, инвентарный номер и категория. При этом насос описывается мощностью и производительностью, емкость — объемом. Если набор категорий расширяется, единая таблица со всеми возможными характеристиками может стать неудобной.

В рабочем хранилище запись значения ссылается на идентификатор определения атрибута; код в таблице показан для удобства чтения. Определение power_kw задает числовой тип и единицу «кВт», а volume_l — числовой тип и литры. Название для интерфейса можно менять независимо от устойчивого кода.

Для нового описательного свойства «материал корпуса» может быть достаточно нового определения и значений. Однако обработка нового формата, бизнес-правило или отчет могут потребовать разработки. EAV не обещает, что любое изменение системы выполняется без релиза.

Что означает гибридная модель

Гибридная модель сочетает обычные поля объекта с расширяемыми характеристиками. В учебном каталоге инвентарный номер и категория остаются основными полями, а технические свойства могут храниться в EAV или JSONB. Выбор расширяемой части определяется задачами, а не названием интерфейсного блока «Детали».

Обязательность не совпадает с местом хранения. Динамический атрибут может быть обязательным для категории «Насос», а обычная колонка — допускать отсутствие значения. Строгость обеспечивают типы, ограничения и проверки, которые нужно описать для обеих частей модели.

Сначала классифицируйте данные по смыслу и операциям. Часто используемое поле — кандидат на обычную колонку или отдельное индексируемое представление, но окончательное решение зависит от запросов. Стабильное свойство подтипа иногда проще вынести в специальную таблицу этого подтипа.

Например, назначение оборудования подразделению — отношение между объектами, а не просто произвольная строка «подразделение». Если назначение имеет даты, ответственного и историю, ему нужна соответствующая модель. Возможность записать ссылку в EAV не отменяет эту семантику.

Когда расширяемая часть оправдана

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

Когда лучше оставить обычную схему

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

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

Сравнивайте варианты на одних и тех же действиях: открыть карточку, найти объекты по нескольким свойствам, отсортировать результат, построить отчет, импортировать данные и изменить определение атрибута. В одной системе могут использоваться несколько вариантов.

Фильтрация, индексы и отчетность

EAV не делает быстрый поиск невозможным, но меняет устройство запросов. Чтобы найти насосы с нужной мощностью и производительностью, нужно проверить оба условия для одного объекта. Могут потребоваться несколько соединений или подзапросов, индексы по определению и типизированному значению. Стоимость проверяют на ожидаемом числе объектов и значений, а не по числу колонок.

JSONB также допускает индексацию: PostgreSQL поддерживает GIN и индексы по выражениям для соответствующих запросов. Выбор индекса зависит от операторов и путей к данным. Подробности описаны в официальном руководстве PostgreSQL ↗.

Если характеристики регулярно участвуют в аналитике, заранее определите представление для отчетов: прямые запросы, представление БД или отдельную витрину. Необходимость отдельного слоя зависит от нагрузки и требований к актуальности. Большой объем EAV-записей сам по себе не означает, что нужна платформа обработки больших данных.

Что действительно получает бизнес

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

Для выбора JSONB отдельно проверьте границу документа, операторы запросов, индексы и конкуренцию обновлений. Учебные запросы и порядок испытаний приведены в руководстве по JSONB в PostgreSQL.

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

Описание атрибута

В руководстве Adobe Commerce по атрибутам ↗ определения включают параметры применимости, уникальности, фильтрации и отображения. Для своей системы нужно выбрать необходимые правила, а не копировать продуктовый набор полей целиком.

Порядок подготовки решения

1. Соберите объекты и категории. Подготовьте реальные примеры из доступных источников, включая редкие и неполные карточки. Для первого разбора можно начать с 20–50 карточек, если они покрывают основные варианты; это рабочий ориентир, а не достаточная выборка для любой системы.
2. Выпишите операции. Укажите фильтры, сортировки, отчеты, обмены, объемы, частоту изменений и согласуемые требования к времени ответа.
3. Классифицируйте данные. Разделите основные поля, переменные свойства, вычисляемые значения и связи. Для каждого спорного поля запишите причину выбора и открытый вопрос.
4. Опишите правила и сравните варианты. Заполните определения атрибутов, проверьте источники истины и выберите хранение под основные операции.
5. Проверьте решение на данных и запросах. Подготовьте пробную загрузку и ключевые выборки. Если ограничения не выполняются, вернитесь к границам модели, индексам или способу хранения до окончательного согласования.

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

Критерии проверки

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

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

Если расширяемая часть передаётся как JSON, её структуру можно проверять по JSON Schema. Для EAV источником определений остаётся согласованный каталог атрибутов; генерация JSON-контракта из него требует явных правил и версий. Схема документа не выбирает физическое хранение и не заменяет проверки прав.

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

Ошибки, которые стоит исключить

• Все спорные поля вынесли в EAV. Вопросы о смысле, обязательности и источниках остались нерешенными и перешли в код и отчеты.
• Все значения записали строками. Числовые сравнения, даты, единицы и проверка типов требуют дополнительных преобразований. Типизированное хранение следует выбрать заранее.
• Разрешили создавать атрибуты без владельца. Появляются разные коды с одним смыслом, несовместимые единицы и противоречивые определения.
• Выбрали модель только по удобству добавления свойств. Не проверили фильтры, отчеты, индексы и стоимость сопровождения.
• Одно значение хранится в нескольких местах. Не определены главный источник и порядок обновления производных представлений.
• Не предусмотрели изменение определений. Новая обязательность, тип или единица делают старые карточки и интеграции несовместимыми.

Что должно получиться

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

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