| |
|
|
| | Доброго дня!
Помогите, пожалуйста, разобраться с принципом организации хранения данных для интернет-магазина.
Ситуация состоит в том, что необходимо представлять множество товаров (тысячи), но они все разношерстные. Т.е. например: отвертки (длина, ширина, тип, ...), лампочки (размеры, вес, мощность, тип цоколя, ...), оборудование (размеры, ток, мощность, вес, характеристики рабочей зоны, ...) и т.д.
Раньше просто работал только с малыми каталогами товаров и при этом однотиповых товаров.
Хранение делал так:
Таблица №1: хранил категории и подкатегории товаров
Таблица №2: хранил коды товаров, цены, описания, характеристики. и привязку к категории в таблице №1
Логика была простой, раскрываем категории в них товары, которые еще доп. можно фильтровать по характеристикам. И соответственно для хлебных крошек всегда можем взять непосредственную категорию принадлежности и подняться по ней вверх по иерархии. Все классно :)
И непонятный вопрос состоит в том, что при наличии разношерстных товаров, я понимаю, что для разных групп товаров необходимо создавать отдельные таблицы для хранения данных.
Видится так:
Таблица №1: располагается дерево иерархии категорий и подкатегорий.
Таблица №2,3,4,5,6...145 и т.д.: тут планирую расположить коды заказов товаров, описания, характеристики, цены, наличие и прочее. и привязку к категории в таблице №1.
И тут не понятки в голове, как понять зная категорию товары из какой таблицы выводить пользователю. При этом вывод товаров из каждой таблицы естественно тоже будет осуществляться своим алгоритмом зашитым в свою для каждой таблицы функцию.
Думается, что может быть есть какой нибудь способ перебрать в цикле все имеющиеся таблицы на факт принадлежности товаров к текущей категории? И писать отдельную функцию по перебору всех таблиц базы данных и сопоставления нужной функции вывода на экран - кажется каким-то бредом!
Может быть кто сможет подсказать, как такое правильно организуют? Пожалуйста, пожалуйста, пожалуйста!!!
P.S.: среди характеристик товаров планируется еще и тегирование с показом соответствующих страниц... :( | |
| |
|
|
| |
|
|
| |
для: mysql_Sergey
(19.06.2015 в 17:01)
| | | Ну а если все характеристики и их значения зашить в две таблицы:
таблица всех характеристик
feature_id | feature_title
таблица связи товара, его характеристики и значения этой характеристики:
product_id | feature_id | feature_value
таким образом можно добавлять сколь угодно много характеристик любому товару. Другое дело, что выборка становится сложнее, например, чтобы выбрать товар у которого цена больше ста и мощность равно 150 придется делать нечто подобное:
<?
select product_id, count(product_id) cnt
from product_features where
(feature_id = 1 #цена
and feature_value > 100)
OR
(feature_id = 2 #мощность
and feature_value = 150)
group by product_id
having cnt = 2 #выбираем только те продукты, у которых обе характеристики совпали
|
+ ко всему с индексами беда. Хотя, если скорость критичный момент, можно наиболее часто используемые характеристики сделать "классическим" вариантом - в таблице товаров, каждая характеристика отдельным столбцом, что, правда, опять же добавляет сложности при выборке))
Также, если время позволяет, можно покопать в сторону других БД. Вроде бы графовые базы здесь помогут, может nosql-решения (с хранением таких структур точно проблем не будет, а вот с поиском - не скажу)
В общем, мысли такие. Может кто еще чего предложит. | |
| |
|
|
| |
|
|
| |
для: Igorek
(19.06.2015 в 17:29)
| | | Спасибо за скорый ответ, мысль реально нравится, но есть смущения.
Выборка получается сложная по сортировке на характеристики (хотя логика нормальная, выбрать все товары (артикулы) с соответствующей категорией которые совпадают с артикулами из выбранной таблицы характеристик по нужным критериям..
Но, сразу думается скорость будет бе... А учитывая, что по мощности будет выборка больше тысячи, сравнивать эти артикулы с списком в 50 шт., чтобы из них выбрать сколько-то. не очень.
Но за идею спасибо, огромное!
Может быть еще кто-нибудь идеи расскажет? Есть же хорошие и крупные интернет-магазины, типа www.vseinstrumenti.ru - не уж то ни кто не знает, как у них там структура товаров хранится... :) | |
| |
|
|
| |
|
|
| |
для: mysql_Sergey
(19.06.2015 в 18:26)
| | | Немного погуглив на эту тему вижу 4 варианта организации БД для магазина, которые мы в общем-то уже упомянули с вами:
1. Одна таблица
Ваш вариант, которым вы раньше пользовались. Все характеристики в одной таблице.
2. Много таблиц
Вариант, который вы предложили - для каждого типа товара своя таблица
3. EAV (Entity–attribute–value)
Вариант, который я предложил. Вроде как magento его использует. Есть улучшения этого подхода, которые позволят увеличить скорость выборки. Если интересно - поиск в помощь, информации тьма в интернетах.
4. Документо-ориентированная база (MongoDB, CouchDB и т.д.)
Отходим от реляционности, которая в данной задаче только палки в колеса ставит и вперед к новому и неизведанному.
Я бы выбрал 4й подход, если есть возможность выбрать не реляционную БД, если нет - то EAV | |
| |
|
|
| |
|
|
| |
для: Igorek
(20.06.2015 в 15:04)
| | | Огромное спасибо за инфу. Ща поищу и почитаю про эту модель. По факту за выходные придумал не совсем реляционную базу, т.е. при категории хранить имя таблицы из которой "черпать" изделия. По концепции SQL не совсем правильно, но зато при совокупном использовании еще запросов из PHP получается "бомба".
Но, естественно со всеми вытекающими придется самому полностью контролировать целостность базы данных (избыточность, дубли, несоответствия, и др...)
И все равно спасибки, гляну на неделе по приведенной инфе... | |
| |
|
|
|
