База данных значений атрибутов сущностей против строгой реляционной модели электронной коммерции

Question

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

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

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

Есть хорошая общая черта среди хороших приложений электронной коммерции, где они показывают набор продуктов, а затем имеют «развернутые» боковые меню, где вы можете увидеть «TV Resolution» в качестве заголовка, и пятерку самых распространенных TV. Разрешения для найденного множества. Вы нажимаете один, и он показывает только телевизоры с таким разрешением, что позволяет вам продолжить детализацию, выбрав другие категории в боковом меню. Эти параметры будут динамическими атрибутами продукта, добавляемыми во время выполнения.

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

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

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

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

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

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

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

Answer 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: хорошая производительность в целом, если только вы не начинаете искать или сообщать по пользовательским атрибутам

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

// At this point, I'd like to take a moment to speak to you about the Magento/<s>Adobe PSD format</s>.
// Magento/<s>PSD</s> is not a good ecommerce platform/<s>format</s>. Magento/<s>PSD</s> is not even a bad ecommerce platform/<s>format</s>. Calling it such would be an
// insult to other bad ecommerce platform/<s>formats</s>, such as Zencart or OsCommerce. No, Magento/<s>PSD</s> is an abysmal ecommerce platform/<s>format</s>. Having
// worked on this code for several weeks now, my hate for Magento/<s>PSD</s> 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 только в том случае, если:

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

Answer 5

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

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

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

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

Answer 6

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

Кажется, что исполнение Magento в формате EAV - настоящая демонстрация.

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

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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

EAV

Массив

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

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