База - ФБ 1.5, вся логика построена на хранимых процедурах, т.е. вся обработка выполняется только на сервере.

Данные - от 1 до 5000-7000 записей о клиентах, каждой из которых может принадлежать от 1 до 20 подчиненных записей из разных таблиц. Кроме того, используются данные из справочников - тарифы, названия улиц и т.д.

В настоящий момент обработка реализована следующим образом: для перерасчёта данных вызывается ХП, в которой имеется 1 for select , включающий 6 union 'ов. В теле selecta'а для каждой записи вызываются несколько других ХП, которые также делают всевозможные запросы к БД для получения уточняющей информации.

Теоритически, наиболее "красивым" решением будет создание вместо нескольких маленьких - одного большого и хитромудрого запроса, который подготовит одну большую выборку со всеми необходимыми данными. После чего по этой выборке делается один проход ... и оп-ля, наши сбоку - ваших нет... Уменьшение трафика, уменьшается число обращений в диску и так далее.

Вопрос заключается в следующем. Есть ли какие-либо ограничения на сложность запроса в ФБ? Сложный запрос состоит, в моём случае, из 6 union'ов, в каждом из которых по 2-5 вложенных друг в друга select'ов. Строка с текстом запроса занимает 5100 байт. И вообще, имеет ли смысл делать такую оптимизацию? Какие тут могут быть подводные камни? Если кто-нибудь проводил сравнение производительности запросов "один большой против нескольких маленьких", поделитесь пожалуйста вашим мнением.

ololЛично я предпочитаю делать авторасчет, т.е. данные расчитываются по мере занесения. В этом случае всегда видно текущее состояние дел и не нужно специально запускать расчет.
Да, у меня именно так и сделано - расчёт производится в тот момент, когда данные заносятся БД. Но по логике работы у меня он выполняется не автоматом, а запускается по специальной кнопочке "Расчитать".

ololА на счет перерасчета - так лучше оставь как есть... (лучшее - враг хорошего) Тем более что разбивка задачи на несколько функционально законченных действия повышает ее читабельность и возможность модернизации... Сам расчет, как я понял, запускается не часто и на его 'вылизывание' не стоит тратить время.
Понял, так и сделаю.

Всем спасибо за ответы.