Стоит ли использовать модель EAV?

Я разрабатываю свою базу данных / домен для приложения электронной коммерции, и мне сложно понять, как хранить продукты.

На сайте будет продаваться широкий ассортимент товаров: ручки, стринги, татуировки, зонтики, все что угодно. Каждый из этих продуктов будет иметь несколько общих атрибутов: высоту, ширину, длину, вес и т. Д., Но у некоторых продуктов есть особые данные. Например, ручки имеют разные цвета чернил, а наконечники / крышки и брошюры могут иметь разные типы складок. Пока что я придумал около 20+ дополнительных атрибутов, но эти атрибуты могут применяться только к 1% товаров на веб-сайте.

Поэтому мне интересно, уместно ли реализовать модель EAV для обработки дополнительных данных. Помните, что, когда клиенты просматривают сайт во внешнем интерфейсе, будет боковая панель фильтрации, как на eBay и carsales.com.au. (Так что, имея в виду, что будет довольно много запросов)

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

Еще я подумал об использовании базы данных NoSQL (возможно, MongoDB), однако у меня мало опыта работы с этими типами баз данных, решит ли это мою проблему?

Обзор вариантов:

  1. Единая сущность продуктов с большим количеством столбцов
  2. Сущность с отдельными атрибутами (EAV)
  3. Переключиться на постоянство без схемы

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

РЕДАКТИРОВАТЬ: Я, конечно, открыт для любых других решений.


php database-design magento doctrine-orm entity-attribute-value
person Cobby    schedule 01.11.2010    source источник
comment
Есть ли конкретная причина, по которой вы создаете приложение для электронной коммерции вручную? Это может быть сложно, опасно и, возможно, немного ненужно ...   -  person Jonathan Day    schedule 01.11.2010
comment
Только что нашел этот вопрос, который кажется почти то же самое, что вы спрашиваете.   -  person BenV    schedule 01.11.2010
comment
@BenV, хотя вопрос похож, ответы, вероятно, будут совершенно разными, особенно в отношении Magento. Magento изначально действительно боролся с производительностью EAV, но они решили эту проблему путем тщательного кэширования (запрос, модель, html-блок и полностраничный) и дополнительной денормализации. Это новые события с тех пор, как был задан этот вопрос, и они заслуживают того, чтобы задать его повторно в этом контексте, ИМХО.   -  person Jonathan Day    schedule 01.11.2010
comment
Приложение, которое я создаю, сильно отличается от типичного приложения электронной коммерции. Единственное возможное существующее решение, которое я нашел в PHP, - это Magento, но оно кажется довольно сложным и будет столь же трудным / трудоемким для меня, чтобы изучить его, а затем сделать свое собственное с нуля.   -  person Cobby    schedule 01.11.2010
comment
@Cobby, честно, вы знаете свои требования лучше, чем кто-либо другой, но при всем уважении, если вы чувствуете, что изучение Magento сложно, то написание собственного приложения для электронной коммерции - это не то, что я рекомендовал бы. Буквально десятки тысяч часов разработчиков и архитекторов потрачены на такие приложения, как Magento, и много боевых шрамов на этом пути. Когда вы имеете дело с деньгами клиентов или клиентов, я бы предпочел, чтобы эти ошибки в прошлом делал кто-то другой, а не я ...   -  person Jonathan Day    schedule 01.11.2010

Ответы (3)


arrow_upward
69
arrow_downward

Отличный вопрос, но, конечно, «единственно верного пути» не существует. Согласно @BenV, Magento использует модель EAV. Мой опыт работы с ним был исключительно положительным, однако он сбивает с толку других пользователей. Некоторые соображения:

1. Производительность. EAV требует сложных многотабличных объединений для заполнения вашего объекта соответствующими атрибутами. Это действительно снижает производительность. Однако это можно смягчить за счет тщательного кэширования (на всех уровнях стека, включая кеширование запросов) и выборочного использования денормализации. Magento действительно позволяет администраторам выбирать денормализованную модель для категорий и продуктов, где это оправдано количеством SKU (обычно в тысячах). Это, в свою очередь, требует наличия наблюдателей, которые запускают повторную индексацию (всегда хорошо!) И обновляют «плоские» денормализованные таблицы при изменении данных о продукте. Это также можно запланировать или запустить вручную с запросом администратора.

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

3. Будущая расширяемость и архитектура плагинов. Нет сомнений в том, что модель EAV действительно вступает в свои права, когда расширяемость является фактором. Добавлять новые атрибуты в модель очень просто, сводя к минимуму риск нарушения существующего кода ORM и контроллера.

4. Изменения в типе данных EAV немного усложняет изменение типов данных атрибутов. Если ваш первоначальный проект требует определенного типа данных атрибута, который изменится в будущем (скажем, с int на varchar), это означает, что вам придется перенести все записи для этого атрибута в соответствующую таблицу, которая соответствует новому типу данных. Конечно, пуристы посоветуют, что вы получите правильный дизайн с первого раза, но реальность иногда вторгается!

5. Ручной импорт продуктов. Одна вещь, которую EAV делает практически невозможной, - это импорт продуктов (или других объектов) в базу данных с использованием SQL и / или phpMyAdmin в стиле CSV / XML. Вам нужно будет написать модуль Importer, который принимает структурированные данные и передает их через уровень модели приложения, чтобы сохранить их в базе данных. Это усложняет вашу работу.

person Jonathan Day    schedule 01.11.2010
comment
Я не думаю, что производительность будет серьезной проблемой, в Doctrine 2 уже есть кеш запросов, плюс я буду реализовывать свой собственный уровень. Кроме того, важно помнить, что атрибуты предназначены только для основных целей: 1. Для фильтрации списков продуктов 2. Отображение на странице продукта. Данные, содержащиеся в атрибутах, являются только метаданными и не являются необходимыми для работы приложения. Я думаю, они немного похожи на теги, и в этом случае EAV кажется практичным. - person Cobby; 01.11.2010
comment
Точка зрения @Cobby Jonathan о кешировании стоит. Как вы генерируете итоги для фильтров? Как эффективно обслуживать страницы для большого количества клиентов? Если вы настаиваете на создании этого самостоятельно, по крайней мере, сделайте себе одолжение и просмотрите изменения, которые Magento внес в свою систему EAV, чтобы обеспечить масштабирование. - person Joseph Mastey; 01.11.2010
comment
Просто играю в адвоката дьявола - Мои чувства точно относятся к EAV: weblogs.sqlteam.com/davidm /articles/12117.aspx#42216 Я не единственный, кто чувствует то же самое: activecodeline.net/f-magento-eav - person B00MER; 29.03.2011
comment
Преимущество модели EAV заключается в том, что изменения в схеме обычно могут быть достигнуты без изменения схемы базы данных. Это важно, потому что в MySQL операторы ALTER TABLE блокируют таблицу, чтобы предотвратить все операции чтения и записи во время изменения схемы. Следовательно, если вам нужно изменить схему для большой таблицы, это может привести к проблемам с блокировкой и возможным сбоям во время выполнения ALTER TABLE. (Подумайте об очень больших и важных таблицах, таких как клиенты или продукты на сайте электронной коммерции). - person Jim OHalloran; 20.01.2012
comment
@JimOHalloran, в производственной среде, где блокировка является серьезной проблемой, было бы довольно стандартно иметь настройку ведущий / ведомый, изменить ведомое устройство, повторно синхронизировать с ведущим, затем поменять местами ведущее / ведомое устройство и следовать тому же процессу. Возможно, вам потребуется написать собственный инструмент для синхронизации двух баз данных, когда они работают в разных структурах, но это будет довольно просто. - person Matt Dunbar; 05.06.2013

arrow_upward
0
arrow_downward

Корзина покупок с открытым исходным кодом Magento позволяет настраивать атрибуты для своих продуктов с использованием дизайна EAV. Вы можете ознакомиться со схемой их базы данных здесь.

person BenV    schedule 01.11.2010
comment
Да, я уже рассмотрел их дизайн базы данных, и на этом я основываю свой прототип. Мой вопрос не в реализации EAV ... Я уже знаю, как его использовать. Мой вопрос касается архитектурной практичности использования EAV в производственной среде. - person Cobby; 01.11.2010

arrow_upward
0
arrow_downward

Я предлагаю вам более внимательно изучить ORM Doctrine 2 с плагином OXM для него (https://github.com/doctrine/oxm). Решит вашу проблему с разными атрибутами. Конечно, вам потребуется создать индексы для настраиваемых атрибутов с возможностью поиска, но я не думаю, что это будет проблемой :)

Если вас не волнует количество участников сообщества, вы также можете использовать MongoDB.

person Ivan Chepurnyi    schedule 11.03.2011