pavelvpНу детский сад какой-то...Глядя на эту реплику возникает прямой вопрос - Вы вообще представляете себе "внутреннюю кухню" СУБД, как она устроена изнутри, или для Вас это "черный ящик" и знания об индексах ограничиваются практикой использования готовой программы?

To all opponents:
----------------------------------------------------------------------
Давайте остановимся в каких-то неконструктивных разборках кто из нас круче и просто вспомним "основы".
----------------------------------------------------------------------
Человечество придумало множество структур данных для очень эффективного решения проблемы поиска информации в большом массиве записей по одному конкретному полю (атрибуту записи) - особенно, если это поле - первичный ключ. Существует множество самых разных организаций индексов, которые ориентированы на разные типы атрибутов и на разные задачи поиска. Например, простые инвертированные списки, B-деревья, битовые карты, хеш-таблицы и их сочетания.
Так же не составляет труда построить эффективно работающий индекс для комплексного ключа, который представляет собой упорядоченное множество атрибутов (полей) собранных вместе. Но для этого мы должны заранее знать особенности распределения значений ключей в базе и типы запросов, которые подает пользователь.
Однако, задача поиска по произвольным полям , выбранным пользователем в процессе работы системы, не решается хорошо через элементарные поиски по отдельным полям и объединение результатов этих поисков пересечением списков или битовых карт.
Не важно, как именно организованы индексы - битовые маски это, B-деревья или что-то иное - если они построены для каждого поля в отдельности , то поиск записей, подпадающих под сложный запрос, включающий несколько полей сразу - будет неэффективным в общем случае .
Это прописная истина, известная со времен какого-нибудь первого издания книжки Кнута про сортировку и поиск.
Не существует в природе и не может существовать алгоритма, который бы сделал эффективным поиск сразу по нескольким полям с использованием ТОЛЬКО отдельных индексов, построенных по конкретным отдельным полям.
Чтобы эффективно искать по произвольному, заранее не зафиксированному при проектировании базы набору полей, нам нужно рассматривать запись как вектор в многомерном пространстве, координатами которого являются значения этих самых полей.
Или же нужно искать другую абстракцию, которая учитывает именно ВЗАИМНОЕ СОЧЕТАНИЕ значений полей, а не смотрит на каждое поле записи в ОТДЕЛЬНОСТИ, в отрыве от значений других полей.
Это - прописные истины.
Поэтому, прежде чем обвинять меня в ламерстве, разберитесь, пожалуйста, с довольно четко и в разных формах описанной постановкой задачи. И не предлагайте решения по сведению 1000-мерного пространства к двумерному через тривиальную укладку в две таблицы.
Есть куча примеров задач, где даже при маленькой размерности любая попытка эффективного поиска в большой базе данных при построении индексов по ОТДЕЛЬНЫМ полям будет неэффективной.
И нельзя построить индекс по одному упорядоченному набору полей, чтобы ускорить произвольный поиск - так как пространство в общем случае изотропное вдоль каждого из измерений, все они равнозначны и фиксируя порядок, мы создаем неэффективность в поиске.
Нужен именно пространственный или какой-то еще более хитрый индекс. Они существуют (R-Tree, GiST, rotating hyperplane и т.п.), но страдают от проблемы "взрыва размерности", необходимости статической предобработки или менее эффективны, чем линейный поиск. Здесь же еще ситуация усложняется ПЕРЕМЕННОЙ размерностью пространства - атрибуты добавляются в процессе работы.