[Guaho]

Благодарю за ответ!
В том-то и дело, что моём приложении, увы, создание форм занимает немалое время. Уж больно много наворочено компонентов на формах. Время создания - порядка 0,5 ... 1 ... 1,5 с для сложных форм, а в сумме набегает более 10 с. На фоне общего времени запуска (порядка 25...30 с) эти 10 с составляют немалую долю, от трети до почти половины.
Как ни странно, при этом инициализация датасетов на большинстве форм занимает меньше времени, чем создание форм - обычно 0,1...0,3 с, редко когда 0,5.
Ещё много времени (но только в сложных случаях, до 3,5 с) сжирает динамическое (по содержимому связанных таблиц) создание деревьев классификации. Деревья - с изображениями, и как их создавать иным способом, я не придумал (хотя есть кое-какие идеи, но это долгая возня с неопределённым результатом).
Остальные рекомендации мне вряд ли подойдут, т.к. либо не подходят под специфику приложения, либо требуют серьёзной перестройки, на что я пойти не могу (разработка длится почти 5 лет, уже нет сил на отклонения от курса).
Ограничить начальный объём данных по датам - нельзя, в этой базе даты не играют никакой роли, а важны сами записи, к любой из которой пользователь может обратиться в любой момент.
Сортировка у меня всегда в TQuery. TTable использую для поиска совпадений с имеющимися данными при добавлении записей (по некоторым причинам вариант с использованием исключений самого движка мне не подошёл).
Lookup-данные у меня прописаны в дизайн-тайме (добавляю в Query стандартные Lookup-поля). Как это делать на уровне SQL-запроса - не знаю.
И потом, в моём случае это не даст ускорения загрузки. Главные тормоза - при создании форм и некоторых деревьев классификации, и только в нескольких случаях - в блоках активации датасетов, но там выполняется ещё куча других действий, отдельно я не замерял.
Забыл сказать: база имеет файл-серверную архитектуру. Записей не особо много - в 1-й главной таблице - менее 2 тыс., во 2-й - менее 4-х тыс. Но - есть графические поля.