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

Question

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

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

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

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

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

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

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

Я в процессе построения прототипа с объектом атрибутов, чтобы увидеть, насколько это гибко, и тестирование производительности и как вне контроля запрос получается.

Редактировать: Я, конечно, открыт для любых других решений.

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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