Должен ли я использовать модель EAV?

Question

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

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

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

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

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

Обзор опций:

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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