Есть задача реализовать удобный поиск в системе. Нашел очень удачное решение на сайте mobile.de:

нажмите кнопку "показать" и см. закладку слева "Ограничить поиск"

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

Делать насчет по общей таблицы записей не представляется возможным во вразумительное время.

Для разбора данной ситуации предлагаю упрощенный вариант с четырьмя измерениями (Бренд, Категория, Модель, Продавец), для решения данной задачи предлагается создать суммирующую таблицу, в которую будут помещаться конечные "предрассчитаные" значения поиска.

-- creating table
CREATE TABLE PRT_SEARCH_HELPER (
    COUNT_       INTEGER,
    BRAND_ID     NUMERIC(18,0),
    CATEGORY_ID  NUMERIC(18,0),
    MODEL_ID     NUMERIC(18,0),
    SELLER_ID    NUMERIC(18,0)
);

Про индексы пока ничего не говорю.

Для построения одной категории (в примрере сумм по категориям) будет делаться запрос вида

select h.category_id, sum(h.count_) from prt_search_helper h where
h.brand_id=ххх
and h.seller_id=ххх
group by
h.category_id

для того, чтобы запрос работал быстро необходимо сдлеать составной индекс по brand_id и seller_id.

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

Уважамые коллеги, конибудь решал подобного рода задачи, если решали то в каком направлении дальше можно оптимизировать данную стуктуру поисковой таблицыее наполнения, построения запросов?