Здравствуйте, senna, Вы писали:
S>Здравствуйте, KRA, Вы писали:
KRA>>3. Что за количество хранится в поле _Count таблицы PRT_SEARCH_HELPER? Я почему спрашиваю, мне не понятно, может ли там быть значение не единица. По виду похоже на количество экземпляров такой-то модели, у такого то продавца. Но тогда не ясно зачем поле бренд, разве одно не однозначно определяется моделью? В общем тут неясность у меня с предметной областью.
S>3. Это количество значений которое получается при выборе конретно бренда, модели, категории, продавца.
S>Соотвественно могут быть строки только с одним полем из бренд, модель, категория, продавец, или комбинированые.
S>Бренд нужен для для оптимизации, вычисление (схлопывание) из значений модели будет более долгим.
Тогда не совсем понятна проблема.
Храните таблицу в том виде, как Вы предложили. При этом там должны быть посчитаны все комбинации (об этом ниже).
При первом показе (т.е. без каких либо наложеных пользовательских критериев) показываете для каждого, скажем, бренда результат запроса
select count_ from prt_search_helper h where
h.brand_id=ххх
Точно так же по другим возможным критериям поиска.
Если пользователь добавляет какой-то критерий поиска (скажем выбирает конкретого продавца), то этот критерий и добавляем в запрос.
Т.е. основная идея, как я писал, выше — никаких групировок во время работы запросов. Все данные должны быть уже подготовлены.
Теперь касательно подсчёта количества для всех комбинаций критериев.
Как лучше сделать зависит от того насколько часто добавляются новые модели/продавцы/бренды/категории, насколько точным должны быть посчитаные количества и насколько мощный сервер
Глобально подхода два:
1. пересчитывать всю таблицу PRT_SEARCH_HELPER
плюсы: проще реализовать
минусы: при каждом добавлении — тяжеловесные запросы. при частых добавлениях — не годится, если слабый сервер/большая загрузка.
2. пересчитывать только то, что собственно изменилось
плюсы: быстрее работает
минусы: сложнее реализовать
В моём приложении новые данные поступали по ночам, тогда я и пересчитывал результаты. В оракле я это делал с помощью group by rollup/cube, в постгресе к сожалению такое не поддерживается, можно сэмулировать union-ами, правда, громоздко получится.
