Объектные кирпичи против классификационного магазина

Pimcore предлагает много возможностей, касающихся моделирования данных для структурированных данных (= Pimcore Data Objects).

Большинство из них являются самоочеми именно разница между индивидуальным выбором.

Кандидатами на такой выбор являются объектные кирпичи и магазин классификации.

Основная цель

Объектные кирпичи и магазин классификации имеют общую цель, которая лучше всего объясняется примером:

В магазине есть продукты разных категорий (например, обувь, палатки, фонарики и т. Д.). Все эти продукты имеют некоторые атрибуты, которые одинаковы для всех категорий (например, имя, фото, описательный текст, статья номер, цвет ...). Эти атрибуты создаются в общем определении класса продукта. Кроме того, есть также атрибуты, которые различаются для каждой категории (обувь имеет единственные профили, палатки имеют Материал пола и фонарики имеют интенсивность света). Все эти атрибуты, конечно, также могут быть созданы в общем Определение класса продукта. Но это приведет к очень большому и запутанному определению класса (= не хорошо). Это лучше Использовать кирпичи объектов или хранилище классификации для этих атрибутов, специфичных для категории.

Вообще говоря, оба типа данных делают определение класса жестких объектов расширяемым на уровне объекта. Конечно, Это не ограничивается только данными продукта, но также может быть практичным для других данных. Атрибуты для обоих типов могут отображаться, отфильтровать и отредактировать в представлении сетки Object.

Технические различия в реализации

	Объектные кирпичи	Классификационный магазин
Параметры дизайна в редакторе объектов	Все параметры макета, предоставленные ExtJS и Pimcore (панели, вкладки, регионы, наборы поля, описания текста, ...) Кирпичи объектов	Все атрибуты расположены между собой в регионах, мало влияния. Классификационный магазин
Доступные типы данных	Практически все типы данных Pimcore, помимо структурированных типов данных, таких как коллекции поля, хранилище классификации, кирпичи объектов	Только очень ограниченные простые типы данных, такие как текстовые поля, цифры, даты, выбирают и мультиселекты (например, также нет отношений).
Хранение данных	Стандартная схема Pimcore в собственных таблицах базы данных с одним столбцом на атрибут.	Схема атрибута объекта (EAV), т.е. в очень длинной таблице баз данных с одной строкой на атрибут (оказывает то же влияние на загрузку и фильтрацию).
Доступ к данным через API	Проще говоря, через Getter и Setter, как известно из объектов Pimcore - см. здесь	Немного сильнее на общих вызовах Getter / Setter - см. здесь
Фильтр в списках объектов	Используя соединения непосредственно в запросе на листинг объекта, см. здесь	Возможно только через пользовательские подраздел и довольно утомительно.

Когда вы что -то используете - контрольный список и эмпирическое правило?

Основное практическое правило может быть

• Пока установлено управляемое количество категорий с определенными атрибутами, скорее используйте кирпичи объектов.
• Как только будет много категорий (более 30) с большим количеством атрибутов, а затем используйте магазин классификации.

Кроме того, есть еще несколько вопросов, которые могут помочь вам принять решение

• Есть ли отношения в атрибутах? В настоящее время работает только с объектными кирпичами
• Нужно ли создавать атрибуты автоматически (например, через интерфейс)? â проще с магазином классификации

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

Если у вас есть какие -либо вопросы, конечно, вы всегда можете связаться с нами ....