Здравствуйте, Аноним, Вы писали:

А>Чуть выше уже приводил структуру
А>Марка
А>* VW (187951)
А>* Mercedes-Benz (122658)
А>* BMW (105710)
А>* Opel (98532)
А>* Audi (97912)

А>вот чтобы это вывести за один запрос, а не за 5 нужен и group by

Так и одним запросом можно без group by

 select count_ from prt_search_helper h where
 h.brand_id is not null and
 h.model_id is null and
 h.category_id is null and 
 h.seller_id is null

Здравствуйте, KRA, Вы писали:

KRA>Так и одним запросом можно без group by
KRA>

KRA> select h.brand_id, count_ from prt_search_helper h where
KRA> h.brand_id is not null and
KRA> h.model_id is null and
KRA> h.category_id is null and 
KRA> h.seller_id is null
KRA>

Здравствуйте, KRA, Вы писали:

KRA>Здравствуйте, KRA, Вы писали:

KRA>>Так и одним запросом можно без group by
KRA>>

KRA>> select h.brand_id, count_ from prt_search_helper h where
KRA>> h.brand_id is not null and
KRA>> h.model_id is null and
KRA>> h.category_id is null and 
KRA>> h.seller_id is null
KRA>>

Поскольку это вопрос моего коллеги, я тоже немного поучаствую

Запрос в таком виде делать нельзя, поскольку он поставит prt_search_helper на фулскан, значения NULL в индексах не хранятся. Но это можно обойти, заменив NULL на какое-нибудь магическое число вроде -1.

Вторая трудность: обойтись расчётом суммирующих записей только для первого уровня выборки не получится, в таблице слишком много записей, чтобы делать фильтрацию даже по двум-трём критериям по "сырым" данным -- не хватает селективности соответствующих составных индексов. Следовательно нужно насчитать суммирующие записи для серьёзного количества комбинаций. Есть какие-то способы этого избежать?

Здравствуйте, <Аноним>, Вы писали:

А>Суть примерно такова, что есть 1 млн записей в базе данных, быстрый поиск по данным записям возможен по примерно 15 категориям. В некоторых категориях может быть до 100 и более значений.

А>Чтобы грубо оценить объем данных в этой таблице необходимо перемножить количества возможных значения измерений, это покроет все комбинации данных значений допустим
А>брендов у нас 100
А>моделей 1000
А>продавцов 100
А>категорий 100
А>получается, около 1 млрд записей, допустим я сделал избыточной данную информацию и часть записей будет с нулевым количеством записей, их можно выкинуть, пусть останется 5-10 млн записей, но это все равно многовато. При 5 млн записей приведный выше запрос отрабатывает за 300мс на машине класса Core 2 Duo 2.5 Ггц, а таких запросов надо делать столько сколько категорий. В итоге получается все равно медленно, ообенно на нагруженной системе.
Этого не может быть. В таблицу помещается результат выполнения запроса

select count(*), brand_id, category_id, MODEL_ID, SELLER_ID from original_table

Очевидно, что он не может вернуть больше записей, чем в original_table. Из миллиона записей невозможно сделать миллиард при помощи группировки

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:

А>>Суть примерно такова, что есть 1 млн записей в базе данных, быстрый поиск по данным записям возможен по примерно 15 категориям. В некоторых категориях может быть до 100 и более значений.

А>>Чтобы грубо оценить объем данных в этой таблице необходимо перемножить количества возможных значения измерений, это покроет все комбинации данных значений допустим
А>>брендов у нас 100
А>>моделей 1000
А>>продавцов 100
А>>категорий 100
А>>получается, около 1 млрд записей, допустим я сделал избыточной данную информацию и часть записей будет с нулевым количеством записей, их можно выкинуть, пусть останется 5-10 млн записей, но это все равно многовато. При 5 млн записей приведный выше запрос отрабатывает за 300мс на машине класса Core 2 Duo 2.5 Ггц, а таких запросов надо делать столько сколько категорий. В итоге получается все равно медленно, ообенно на нагруженной системе.
S>Этого не может быть. В таблицу помещается результат выполнения запроса
S>

S>select count(*), brand_id, category_id, MODEL_ID, SELLER_ID from original_table
S>

S>Очевидно, что он не может вернуть больше записей, чем в original_table. Из миллиона записей невозможно сделать миллиард при помощи группировки

Миллион записей у mobile.de, а у нас до 100 млн. и в суммирующей таблице будет 5-10 млн записей

Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>Миллион записей у mobile.de, а у нас до 100 млн. и в суммирующей таблице будет 5-10 млн записей
Ну... 10 млн — это всё еще в 100 раз лучше, чем 1 млрд.
Если этого всё еще слишком много — введите еще один уровень свёртки. Выкиньте модель и получите

CREATE TABLE PRT_SEARCH_HELPER (
    COUNT_       INTEGER,
    BRAND_ID     NUMERIC(18,0),
    CATEGORY_ID  NUMERIC(18,0),
    SELLER_ID    NUMERIC(18,0)
);