Я разрабатываю свою базу данных / домен для приложения электронной коммерции, и мне сложно определить, как хранить продукты.
На сайте будет продаваться широкий ассортимент продукции, ручки, стринги, татуировки, зонтики и многое другое. Каждый из этих продуктов будет иметь несколько общих атрибутов, высоты, ширины, длины, веса и т. Д., Но некоторые продукты имеют специальные данные. Например, ручки имеют разные цвета чернил, а кончики / крышки и брошюры могут иметь разные типы складок. До сих пор я придумал еще 20 дополнительных атрибутов, но эти атрибуты могут применяться только к 1% продуктов на веб-сайте.
Поэтому мне интересно, целесообразно ли реализовать модель EAV для обработки дополнительных данных. Помня о том, что, когда клиенты просматривают сайт в интерфейсе, появится боковая панель фильтрации, например, на eBay и carsales.com.au. (Таким образом, имея в виду, будет справедливая часть запросов)
Я не думаю, что было бы практично реализовать наследование Class Table, поскольку система должна оставаться гибкой. Это связано с тем, что в будущем мы можем иметь больше атрибутов в новых продуктах.
Другая вещь, которую я рассмотрел, – это использование базы данных NoSQL (возможно, MongoDB), но у меня мало опыта работы с этими типами баз данных, она даже решит мою проблему?
Обзор вариантов:
Я собираюсь создать прототип с сущностью атрибутов, чтобы увидеть, насколько он гибкий, и проверить производительность и как неконтролируемый запрос.
EDIT: Я, конечно, открыт для любых других решений.
Большой вопрос, но, конечно, нет «одного истинного пути». Согласно @BenV, Magento использует модель EAV. Мой опыт работы с ним был в целом положительным, однако он запускает других пользователей. Некоторые соображения:
1. Производительность. EAV требует сложного объединения нескольких таблиц для заполнения вашего объекта соответствующими атрибутами. Это наносит удар производительности. Однако это можно смягчить путем тщательного кэширования (на всех уровнях через стек, включая кэширование запросов) и выборочного использования денормализации. Magento позволяет администраторам выбирать денормализованную модель для категорий и продуктов, где это гарантирует количество SKU (обычно в тысячах). Это, в свою очередь, требует, чтобы наблюдатели запускали повторную индексацию (всегда хорошо!) И обновляли «плоские» денормализованные таблицы при изменении данных о товаре. Это также можно планировать или вручную запускать с приглашением администратора.
2. Сложность сторонних пользователей Если вы когда-либо планируете сделать это приложение доступным для других пользователей, многие из них найдут слишком много EAV, и в конечном итоге вы столкнетесь с большим блеском и неосведомленным злоупотреблением на форумах пользователей (ref Magento !!) ,
3. Будущая расширяемость и архитектура плагина. Несомненно, что модель EAV действительно приходит в себя, когда расширяемость является фактором. Очень просто добавлять новые атрибуты в модель, сводя к минимуму риск нарушения существующего кода ORM и контроллера.
4. Изменения в типе данных EAV затрудняют изменение типов данных атрибутов. Если ваш первоначальный проект вызывает конкретный тип данных атрибута, который изменяется в будущем (например, int to varchar ), это означает, что вам придется перенести все записи для этого атрибута в соответствующую таблицу, соответствующую новому типу данных. Конечно, пуристы предположили бы, что вы получите дизайн в первый раз, но реальность иногда вторгается!
5. Ручные импортные товары Одна вещь, которую EAV делает практически невозможной, – это импорт продуктов (или других объектов) в базу данных с использованием CSV / XML в формате SQL и / или phpMyAdmin. Вам нужно будет написать модуль Importer, который принимает структурированные данные и передает его через слой модели приложения, чтобы сохранить его в базе данных. Это добавляет вашей сложности.
Корзина Magento с открытым исходным кодом позволяет настраивать атрибуты своих продуктов с использованием дизайна EAV. Здесь вы можете проверить схему своей базы данных.
Я предлагаю вам взглянуть ближе на ORM Doctrine 2 с плагином OXM для него (https://github.com/doctrine/oxm). Он решит вашу проблему с разными атрибутами. Конечно, вам нужно будет создавать индексы для пользовательских атрибутов, доступных для поиска, но я не думаю, что это будет проблемой 🙂
Если вас не волнует количество членов сообщества, вы также можете использовать MongoDB.