Подсчет количества значений возможных свойств при выводе списка продуктов

[ustasby]

Подсчет количества значений возможных свойств при выводе списка продуктов

Считаю что тема подходит под теорию, а теперь к задачке

http://www.citilink.ru/catalog/monitors_and_office/consumables/cartridges/ - это просто пример реализации, а не реклама, пример фильтра с подсчетом количества позиций в каждом значении свойства. И если с наличием, статусом, брендом и ценой все понятно, и реализуется четырьмя запросами (наличие и статус - это 1, бренд - это 2, и цена - 3 и 4), то со значениями свойств я предположить подсчет за один проход даже не могу.

Обычный вариант - объект, свойства, значения мне понятен, и легко реализуем, тут случай другой, как же они считают количество продуктов с этим значением? Динамически строят запрос count на каждое значение свойства которое указано к выводу в категории, что то похожее на

select ..... count('копиры'), count('плоттеры') и так далее по списку возможных значений для данной категории

под "count('копиры')" подразумевается id этого значения в таблице.

Может кто то и знаком с таким подходом, и разжует?

 

[grigori]

не вижу теории, вижу вопрос по составлению запроса к базе

 

[ustasby]

странно, но почему мы таких запросов не видим в большинстве магазинов? Не все так просто в этом случае, и запросом тут явно не обходится. Если бы обошлось составлением запроса, я бы и вопрос не задавал.

 

[AmdY]

можно подзапросом
SELECT *, (SELECT COUNT(*) FROM catelog_product p WHERE p.id_categoies = c.id)
FROM catalog_categories c
а можно просто в категории добавить поле в котором "кэшируется" колличество и обновляется при продаже, удалении товаров

 

[ustasby]

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

 

[AmdY]

ustasby
тогда второй вариант, хранишь счётчики, при добавлении товара увеличиваешь новые, при удалении убираешь.

 

[ustasby]

AmdY
Ты глянь реализацию, там не пахнет счетчиками. В magento я посмотрел реализацию, короче я ее больше смотреть не хочу, у них очень странное видение мира.

 

[HraKK]

90% уверен что решается это без вложенных запросов, сегодня просто времени нету подумать над запросом

 

[AmdY]

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

 

[ustasby]

Пример запроса в ecart

FROM `catalog_product` AS `p`

INNER JOIN `catalog_product_attribute` AS `pa` ON p.id = pa.product_id
INNER JOIN `catalog_product_option` AS `po` ON pa.product_option_id = po.id
INNER JOIN `catalog_product_option_text` AS `pot` ON pa.product_option_id = pot.product_option_id
INNER JOIN `catalog_product_option_value_text` AS `povt` ON pa.product_option_value_id = povt.product_option_value_id
INNER JOIN `catalog_product_category` AS `ptc` ON p.id = ptc.product_id
INNER JOIN `catalog_category` AS `c` ON ptc.category_id = c.id

 

[grigori]

в любом случае, это вопрос по конкретной проблеме, теории тут нет

 

[ustasby]

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

 

[HraKK]

теория как это сделать, и что бы ресурсы не кушало

Это практика, причем никому не интересная. Кроме тебя.

 

[Вурдалак]

HraKK, за всех-то не говори.

 

[HraKK]

Вурдалак
ок, решай

 

[vovanium]

Имхо самый простой вариант у тебя есть связка продукт_id-свойство_id, добавляешь одно избыточное поле категория_id, соответсвенно одним запросом достаешь все свойства для категории, группируешь по свойство_id, и count по каждому свойству

 

[grigori]

Вурдалак, ustasby
на этом сайте несколько человек решают за всех,
это не я придумал, но мы со HraKK из числа тех, кто решает за вас
извините, таковы правила

 

[AmdY]

кстати. сейчас делаю магазин, использую доктрину. хочется иметь в каталоге товары разных классов с разными наборами полей и поиском по них.
городить общую таблицу с аттрибутами не хочется, может стоит попробовать генерировать таблицы при изменеии атрибутов, но думается будут проблемы с поиском
если делать кучу, то получется примерно такая структура, какие есть есть советы и замечания. (особенно с учётом doctrine orm)
items
id (id_item) | title | price ... | id_type

attribute
id (id_type) | title

attribute_value
id | id_item | value

-~{}~ 05.11.10 13:21:

товарищ HraKK, очень нид хелп, у тебя же опыт есть богатый сексуальный опыт с магазинами

 

[HraKK]

товарищ HraKK, очень нид хелп, у тебя же опыт есть богатый сексуальный опыт с магазинами

Чем помочь? решить проблему ТС? Или у тебя другая?

-~{}~ 05.11.10 13:36:

(особенно с учётом doctrine orm)

я ее не знаю в совершенстве, поэтому мои советы не помогут тебе.

У меня в магазине атрибуты сделаны так

attributes
id | alias

attributes_description
idAttribute | idLanguage | name

attributes_to_category
idCategory | idAttribute | position

attributes_value
id | idAttribute | alias

attributes_value_description
idValue | idLanguage | name

attributes_value_to_product
id | idProduct | idValue | modification | active

 

[AmdY]

HraKK
огромное спасибо. то что нужно, проблы в вопросе ТС не вижу, там несколько вариантов можно придумать в зависимости от стуруктуры бд и инструметов.
я как представил сколько мне шишек предстояло набить, аж больно стало. чёто только в голову структура не кладётся схема, тяпница небось, нужно будет в воскресенье обмозговать.