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

Question

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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