Laravel Как лучше организовать БД такого вот Интернет-магазина?

[Petja]

Большой Интернет-магазин, есть много вложенных категорий и различных товаров (с разными свойствами, структурой).

Я пока вижу 2 пути:
1) Полиморфические связи один ко многу.
Есть ресурс, ресурс бывает товар, страница и т.п.
Товар может быть медицинский, туристический и т.п.
туристический товар может быть такого-то типа, товар такого-то типа имеет такие-то свойства.

*Тут вижу сложность с добавлением посреднических узлов в цепочке, а так же сложность со сквозными связями (Through) из-за длинны цепочки.

2) Упростить полиморфические связи из п.1, ресурс -> товар -> конкретный товар со своими свойствами. А категории товаров вынести отдельно в дерево...

Магазин рассчитан на рост и правки, чтобы легко можно было добавлять узлы, категории и т.п. Подскажите, какие еще есть решения в проектировании такой БД?

Заранее благодарю!

 

[Redjik]

Откажись от заказа - сделай пару магазинов на товары с одинаковой структурой.
Не потянешь пока.

 

[Petja]

Откажись от заказа - сделай пару магазинов на товары с одинаковой структурой.
Не потянешь пока.

Я себе делаю! Ты меня не знаешь как и я тебя не знаю. Ты веришь в ясновидение?
Я не буду просить раскрыть всю твою логическую цепочку: как конкретно ты мог прийти к такому выводу. Потому что мне все равно, и потому что мне некогда. Я задал вопрос - у меня проблема, я ищу помощи, если ты не в состоянии помочь, то не отвечай мне, мне некогда пипирками меряться у меня нет на это времени.

Господи, чтож за детский сад....

 

[Redjik]

Ты веришь в ясновидение?

Есть ресурс, ресурс бывает товар, страница и т.п.

Тут уже и так все понятно =)))

В базе 1 таблица с товаром с полями - общие свойства.
Частные свойства - EAV.
Категори - дерево.
Товар принадлежит категории.
из EAV - часть с A - связана с категориями, часть V связано с товаром.

Развлекайся - приходи через пару месяцев.

 

[Petja]

Есть ресурс, ресурс бывает товар, страница и т.п.

Тут уже и так все понятно =)))

Я хочу сделать БД максимально семантической - понятной и разделенной логически, потому что где угодно может всплыть необходимость что-то добавить или убрать.
Ресурс (я сам придумал это) - это абстрактный объект первичного уровня, может быть разных типов, в него можно добавлять что-то общее для всех объектов.
Я просто такое предположил, что было - то и написал.

В базе 1 таблица с товаром с полями - общие свойства.
Частные свойства - EAV.
Категори - дерево.
Товар принадлежит категории.
из EAV - часть с A - связана с категориями, часть V связано с товаром.

В принципе, самый простой и логичный способ (вроде как), я его знаю (это единственный нормальный способ проектирования БД магазина, который я практиковал). Благодарю за конструктивный ответ.
Просто хотелось, чтобы объекты максимально друг от друга абстрагировались, ведь еще не понятно что за продукты, страницы и какие еще объекты там могут появиться и с какой дальнейшей разветвленностью. А так же может понадобиться структурировать не только по категориям а по чему-то еще. Хочется быть готовым ко всему.

Развлекайся - приходи через пару месяцев.

Вот тут не понял.

 

[Redjik]

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

на старницы - таблица pages
на остальные обьекты - заводишь в базу еще таблицы, серебряной пули нет - всех вариантов не учесть
кончено ты можешь писать пару лет вариант на все случаи жизни, потом запустишь на нем пару бложиков и забьешь =))

А так же может понадобиться структурировать не только по категориям а по чему-то еще.

То есть ты сам еще не придумал, но надо да? =)
И яндекс маркет не придумал.
И крупные магазины ...

Просто хотелось, чтобы объекты максимально друг от друга абстрагировались

у тебя наоборот получается дичайшая связанность всех компонентов системы

 

[grigori]

Petja, Redjik советует забить не из вредности.
Мы эту задачу решили - команде из 5 человек нужен примерно год.
он просто понимает объем работы

попробуй сделать на пакете: Magento, OSCommerce, десятки их

 

[Petja]

Благодарю! Понял так - или начинать с простого, или будет слишком не просто.
Значит начну с простого. Да, пока не известно какая будет структура, потому что я иду по схеме:
тестирую товар, если продается - добавляю в магазин и так далее. То етсь сначала будет 1 тематика и пара товаров, а в перспективе, если повезет, то будет крупный магазин с кучами категорий.