Добрый день.
Извините за "назойливость", вернулся к старой теме.
Ранее я задавал вопрос, как получить все записи карточки,
(см. тему Формирование запроса).
А.Ковязин предложил вариант.
select distinct tc.id, tc.id_car, tc.f_znak, tc.f2
from testcard tc
join testcard tc2
on (tc.id_car=tc2.id_car and (tc2.f_znak like 'X1%' ))
Можно было бы добавить и такой:
select b.* from testcard a inner join testcard b on a.id_car=b.id_car
where a.f_znak like 'X1%' and a.id=b.id
union
select b.* from testcard a inner join testcard b on a.id_car=b.id_car
where a.f_znak like 'X1%' and a.id!=b.id
Результат тот же, но количество считываний по индексу больше
приблизельно в 2 раза, т.е. общее время выполнения существенно
больше предыдущего.
Но это для одной таблицы. В жизни так не бывает.
Например, имеем список граждан (ниже таблица t2).
Поля F1,F2 - информация о гражданах.
Таблица t1 - главная, она содержит ключ сязи с t2 (id_t2),
идентификатор группы (карточки) id1 и другую свою информацию.
Задание, получить реестр всех групп, в которых присутствует некие лица
(т.е. накладывается условие, например, t2.f1 like 'A1%')

Таблица t1
create table t1 (
ID INTEGER NOT NULL,
ID_T2 INTEGER NOT NULL,
ID1 INTEGER NOT NULL,
F1 CHAR(10)
);
Таблица t2
create table t2 (
ID INTEGER NOT NULL,
F1 CHAR(10),
F2 CHAR(10)
);
ALTER TABLE T1 ADD CONSTRAINT PK_T1 PRIMARY KEY (ID);
ALTER TABLE T2 ADD CONSTRAINT PK_T2 PRIMARY KEY (ID);
CREATE INDEX T1_ID1 ON T1 (ID1);
CREATE INDEX T2_F1 ON T2(F1);

Данные t1:
ID ID_T2 ID1 F1
1 1 1 Y1
2 2 1 Y2
3 4 2 Y3
4 4 3 Y4
5 5 3 Y5
Данные t2:
ID F1 F2
1 A1 C1
2 A2 C1
3 B1 P1
4 X1 Z1
5 X1 Z2

Мой вариант, прекрасно подходящий для oracle и mssql:
select t1.*,t2.* from t1,t2 where t1.id_t2=t2.id and t1.id1 in
(select t1.id1 from t1,t2 where t1.id_t2=t2.id and t2.f1 like 'A1%')
результат:
id_a id_t2 id1 f1_a id_b f1_b f2
1 1 1 Y1 1 A1 C1
2 2 1 Y2 2 A2 C1
Но для IB использование подзапросов увы...
Кто что может предложить для решения этой задачи под IB?
Определяющим является скорость выполнения запроса.
Кроме того, в реальной системе у меня несколько таких таблиц t2,
связанных воедино таблицей t1.
Может этот подход неверен? Может кто предложит другой вариант
организации БД.