Доделал. По ходу работы я решил кое-что изменить. А именно: добавить 2 временные таблицы для хранения промежуточных результатов (там идентификаторы Vehicle – только одно поле). Запросы просто летают, тут даже потестил на большее, чем 10 число условий – базе пока что всё равно. Оно и понятно – сложных-то соединений нет. Данных, конечно, у меня пока немного, но вроде всё адекватно ищется.

Почему сделал 2 временные тыблицы: я разбиваю сложный запрос на такие подзапросы: либо ...AND...AND... либо ...OR...OR... Там могут быть какие угодно условия, главное чтобы не пришлось возиться со сложным соединением таблиц.

Я решил, что лучшее - враг хорошего и не стоит пихать в один запрос много таблиц со сложными соединениями. Тем более, что формировалось бы всё это автоматом и про производительность сложно было бы что-то сказать. А так, поэкспериментировал с различными формами этих простых запросов, убедился, что они достаточно эффективны и написал в программе функцию, которая разбирает запрос и образует список запросов в нужном порядке для последовательного выполнения. На каждом этапе после выполнения данные заносятся во временную таблицу, а потом производится либо объединение новых результатов с сохранёнными, либо пересечение.

Что-то у меня не сработало в одной команде сначала объединение двух таблиц, а потом вставка их в третью. Это ограничение Firebird или я не так что-то делаю INSERT INTO T3 (ID) (SELECT ID FROM T1 UNION SELECT ID FROM T2) ? Я написал процедурку, которая делает эту вещь, но немного по-другому, без UNION. Но, вообще, странно…

И вот у меня вопрос, а насколько эффективен запрос, состоящий из двух: основного, который в своём условии содержит конструкцию SELECT … WHERE ID IN (SELECT ID FROM SOMETABLE). И его пара NOT IN, понятно. Поля ID каждой из таблиц индексированы (первичные ключи). Сдаётся мне, что сервер быстро выполнит этот запрос, но где-то читал, что на больших объёмах таблиц оператор IN лучше не применять. Что скажете по этому поводу? Использовать его или нет?