Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Большой Интернет-магазин, есть много вложенных категорий и различных товаров (с разными свойствами, структурой).
Я пока вижу 2 пути:
1) Полиморфические связи один ко многу.
Есть ресурс, ресурс бывает товар, страница и т.п.
Товар может быть медицинский, туристический и т.п.
туристический товар может быть такого-то типа, товар такого-то типа имеет такие-то свойства.
*Тут вижу сложность с добавлением посреднических узлов в цепочке, а так же сложность со сквозными связями (Through) из-за длинны цепочки.
2) Упростить полиморфические связи из п.1, ресурс -> товар -> конкретный товар со своими свойствами. А категории товаров вынести отдельно в дерево...
Магазин рассчитан на рост и правки, чтобы легко можно было добавлять узлы, категории и т.п. Подскажите, какие еще есть решения в проектировании такой БД?
Заранее благодарю!
Не в сети
Я бы сделал справочник категорий, типов, свойств (зависящих от категорий и типов). Категория и тип - это по-хорошему признак товара (n:1, товар принадлежит категории и типу - или даже просто типу, а категория - это признак типа), а и уже кроссами (n:m) связывал конкретный товар с соответствующими свойствами.
В такой структуре категории и даже типы можно реализовывать в виде деревьев (реализовывать вложённости сколь угодно сложные), все товары того или иного типа будут обладать определённым, настраиваемым набором свойств (обинаковым для одного типа, но при этом, отличающимся от другого типа), можно будет производить поиск по любому из свойств типа, формирвоать динамические фильтры по свойствам в зависимости от типа товара, сравнения и прочее...
Слабым же местом в этой истории является, по-моему, Eloquent. В текущей его реализации определённые запросы будут не до конца оптимальными (можно попасться на хорошие тормоза, если ограничение выдачи будет настраиваемой и в максимальном выражении очень большой). Нужно будет писать не ORM запросы. Но это не очень страшно, так как будет работать только на списках с фильтрацией. Плюс - грамотное кэширование спасёт отца русской демократии.
Не в сети
SMGladkovskiy, благодарю! Буду теперь переваривать ваше предложение, не сталкивался с понятием справочник, теперь есть возможность погуглить и узнать много нового.
А для деревьев планирую использовать: http://packalyst.com/packages/package/baum/baum
Не в сети
Всегда пожалуйста!
По поводу библиотеки для nested sets - по описанию хороша. Даже с поддержкой soft delete. Для инет магазина, если будет интеграция с учётными системами, полезно...
Не в сети
Страницы 1