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

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

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

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

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

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

// 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

внутренние модели в лучшем случае дурацкие, как кто-то положил схему в игру boggle, запечатал это и положил его в краскораспылитель...

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

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. вы получили большие мешки денег!--20-->
2. вы должны
3. наслаждайтесь боль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЕАВ

массив

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

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