База данных атрибутов Entity по сравнению с строгой реляционной моделью Электронная торговля

Можно с уверенностью сказать, что модель базы данных EAV/CR плохая. Тем не менее,

Вопрос: Какую модель, метод или шаблон базы данных следует использовать для обработки "классов" атрибутов, описывающих продукты электронной торговли, которые можно изменить во время выполнения?

В хорошей базе данных электронной коммерции вы будете хранить классы параметров (например, разрешение телевизора, то есть разрешение для каждого телевизора, но следующий продукт может не быть телевизором и не иметь "ТВ-разрешение" ). Как их хранить, эффективно искать и разрешать пользователям устанавливать типы продуктов с переменными полями, описывающими их продукты? Если поисковая система обнаруживает, что клиенты обычно ищут телевизоры на основе глубины консоли, вы можете добавить глубину консоли в свои поля, а затем добавить единую глубину для каждого типа продукта tv во время выполнения.

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

Дальнейшее обсуждение:

Короче говоря, есть ли какие-либо ссылки в Интернете или описания моделей, которые могли бы "научным образом" исправить следующую настройку? Я благодарю Ноэля Кеннеди за предложение таблицы категорий, но это может быть больше этого. Я описываю это иначе, пытаясь подчеркнуть значение. Мне может понадобиться коррекция точки обзора для решения проблемы, или мне может понадобиться глубже проникнуть в EAV/CR.

Полюбите положительный ответ на модель EAV/CR. Мои коллеги-разработчики все говорят о том, что Джеффри Кемп затронул ниже: "новые объекты должны быть смоделированы и спроектированы профессионалом" (из контекста, прочитайте его ответ ниже). Проблема заключается в следующем:

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

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

отдел/поиск по ключевым словам/сравнительная таблица между аналогичными продуктами
Конфигурация потребительского продукта перед оформлением заказа

Атрибуты должны иметь значение, а не только поиск по ключевым словам. Если они хотят сравнить все торты с "взбитыми сливками", они могут щелкнуть лепешками, нажать тему дня рождения, щелкнуть взбитыми сливками, затем проверить все торты, которые интересны, зная, что у всех есть взбитые сливки. Это не относится к торты, просто пример.

Ответ 1

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

Вариант 1, модель EAV:

Pro: меньше времени на разработку и разработку простого приложения.
Pro: новые объекты легко добавлять (может даже могут быть добавлены пользователями?)
Pro: "общие" компоненты интерфейса
Con: сложный код, необходимый для проверки простых типов данных
Con: намного сложнее SQL для простых отчеты
Con: сложные отчеты могут стать почти невозможно
Con: низкая производительность для больших наборов данных

Вариант 2, Моделирование каждого объекта отдельно:

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

Вариант 3, Комбинация (объекты модели "правильно", но добавьте "расширения" для пользовательских атрибутов для некоторых/всех сущностей)

Pro/Con: требуется больше времени для сбора требований и дизайна, чем вариант 1, но, возможно, не так много, как вариант 2 *
Con: новые объекты должны быть смоделированы и спроектированы профессиональным
Pro: новые атрибуты могут быть легко добавлены позже
Con: сложный код, необходимый для проверки простых типов данных (для пользовательских атрибутов)
Con: компоненты пользовательского интерфейса все еще требуются, но для пользовательских атрибутов могут быть доступны общие интерфейсные компоненты
Con: SQL становится сложным, как только любой настраиваемый атрибут включен в отчет
Con: хорошая производительность в общем случае, если вы не начнете искать или сообщать пользовательские атрибуты

* Я не уверен, что Option 3 обязательно сохранит любое время на этапе разработки.

Лично я склоняюсь к варианту 2 и избегаю EAV, где это возможно. Однако для некоторых сценариев пользователям нужна гибкость, которая поставляется с EAV; но это связано с большими затратами.

Ответ 2

Можно с уверенностью сказать, что модель базы данных EAV/CR плохая.

Нет, нет. Это просто неэффективное использование реляционных баз данных. Чистое хранилище ключей/значений отлично работает с этой моделью.

Теперь, к вашему реальному вопросу: как хранить различные атрибуты и сохранять их в поиске?

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

EAV/CR становится уродливым, когда вы используете его для замены "реальных" полей. Как и в случае с каждым инструментом, чрезмерное использование "плохого" и плохое изображение.

Ответ 3

// At this point, I'd like to take a moment to speak to you about the Magento/Adobe PSD format.
// Magento/PSD is not a good ecommerce platform/format. Magento/PSD is not even a bad ecommerce platform/format. Calling it such would be an
// insult to other bad ecommerce platform/formats, such as Zencart or OsCommerce. No, Magento/PSD is an abysmal ecommerce platform/format. Having
// worked on this code for several weeks now, my hate for Magento/PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.

http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

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

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

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id, 
       sales_order_entity.entity_id, 
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
       GROUP_CONCAT( 
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!' 
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

Точная информация о адресе для заказа, лениво

Резюме: Используйте только Magento, если:

Вам дают большие мешки с деньгами.
Вы должны
Наслаждайтесь болью

Ответ 4

Я удивлен, что никто не упоминает базы данных NoSQL.

Я никогда не практиковал NoSQL в производственном контексте (просто протестировал MongoDB и был впечатлен), но вся точка NoSQL может сохранять элементы с различными атрибутами в одном и том же "документе".

Ответ 5

В тех случаях, когда производительность не является основным требованием, как и в типе приложения ETL, EAV обладает еще одним отличительным преимуществом: дифференциальная экономия.

Я реализовал ряд приложений, в которых требование переархивации заключалось в возможности увидеть историю объекта домена с его первой "версии" до текущего состояния. Если этот объект домена имеет большое количество атрибутов, это означает, что каждое изменение требует, чтобы в него была вставлена новая строка (не обновление, потому что история будет потеряна, но вставка). Позвольте сказать, что этот объект домена - это Личность, и у меня есть 500K человек для отслеживания со средним числом 100 изменений в жизненном цикле Лица к различным атрибутам. Пара, что с редким случаем является приложение, которое имеет только 1 основной объект домена, и вы быстро поймете, что размер базы данных быстро будет выходить из-под контроля.

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

Все модели меняются со временем, чтобы отражать новые потребности бизнеса. Период. Использование EAV - это лишь один из инструментов в нашей коробке; но он никогда не должен автоматически классифицироваться как "плохой".

Ответ 6

Я борюсь с той же проблемой. Возможно, вам будет интересно ознакомиться со следующим обсуждением двух существующих решений для электронной коммерции: Magento (EAV) и Joomla (регулярная реляционная структура): https://forum.virtuemart.net/index.php?topic=58686.0

Кажется, что производительность Magento EAV является настоящим шоу-оператором.

Вот почему я склоняюсь к нормализованной структуре. Чтобы преодолеть недостаток гибкости, я подумываю о добавлении в будущем некоторого отдельного словаря данных (XML или отдельных таблиц БД), который может быть отредактирован, и на основе этого код приложения для отображения и сравнения категорий товаров с набором новых атрибутов будет сгенерированы вместе со сценариями SQL.

Такая архитектура, похоже, является sweetspot в этом случае - гибкой и эффективной в то же время.

Проблема может быть частым использованием ALTER TABLE в живой среде. Я использую Postgres, поэтому его MVCC и транзакционный DDL, надеюсь, облегчат боль.

Ответ 7

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

Ответ 8

Если это касается атрибутов каталога товаров и, следовательно, требований к проверке для этих атрибутов, весьма ограничены, единственным реальным недостатком EAV является производительность запросов, и даже это проблема только в том случае, если ваш запрос имеет дело с несколькими "вещами" (продуктами) с атрибутами, производительность для запроса "дайте мне все атрибуты для продукта с id 234", в то время как не оптимальная, все еще достаточно быстро.

Одним из решений является использование модели базы данных SQL/EAV только для стороны администрирования/редактирования каталога продуктов, а также некоторый процесс, который денормализует продукты во что-то, что делает его доступным для поиска. Поскольку у вас уже есть атрибуты, и, следовательно, скорее всего, вы хотите получить грань, это может быть Solr или ElasticSearch. Этот подход позволяет избежать практически всех недостатков модели EAV, а добавленная сложность ограничивается сериализацией полного продукта для JSON при обновлении.

Ответ 9

EAV имеет множество недостатков:

Снижение производительности с течением времени Как только количество данных в приложении будет превышать определенный размер, поиск и обработка этих данных, вероятно, станут менее эффективными.
SQL-запросы очень сложны и трудны для записи.
Проблемы целостности данных. Вы не можете определить внешние ключи для всех необходимых полей.
Вам необходимо определить и сохранить свои собственные метаданные.

Ответ 10

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

Я сделал небольшой набор тестов, чтобы сравнить два дизайна: один с использованием EAV, а другой с помощью массива Postgres ARRAY для хранения данных ячейки.

EAV

Массив

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

Оказалось, что схема на основе массива была на порядок быстрее для обеих вставок и запросов. Из быстрых тестов казалось, что оба масштабируются линейно. Однако тесты не очень тщательны. Предложения и вилки приветствуются - они находятся под лицензией MIT.