Есть большой проект на Delphi 2007 - больше 400 тысяч строк.
Весь проект построен главным образом на базе
TIBDatabase, TIBTransaction, TIBQuery, TDataSource, TDBGrid
(разумеется, есть еще много используемых компонентов - но это основное)
Проблема в IBX в том, что это устаревшее решение и медленно работает при подключении к базам данных через Интернет-соединение. Например, если ping между 2 компьютерами 20 миллисекунд - выполнением одного небольшого Select (даже возвращающего всего 1 запись) занимает около 80-100 миллисекунд (то есть в 4-5 раз дольше, чем обычный ping).
Другое дело в случае с правильно настроенным FireDAC. Время выполнения Select может быть 20-40 миллисекунд (то есть 1-2 обычных ping вместо 4-5). Соответственно, если всё приложение перевести с IBX на FireDAC - скорость его работы существенно возрастёт при подключении к базе данных через Интернет (где ping между компьютерами не 1-2 миллисекунды, как в локальной сети, а даже 20 мс считается хорошим).
Теперь остаётся вопрос в том - как перевести проект с IBX на FireDAC - чтобы программный код проект этого "почти не заметил"?
Как я понимаю, потребуется переопределить классы TIBDatabase, TIBTransaction, TIBQuery - чтобы они работали на базе FireDAC (используя классы TFDConnection TFDTransaction TFDQuery) и подключить переопределённые классы ко всем формам проекта - после подключения стандартных модулей IBX.
При обращении приложения - скажем, к TIBQuery.Open промежуточный класс должен образаться к TFDQuery и т. д. Еще в приложении для TIBQuery используется множество обработчиков событий AfterScroll, OnGetText и т. д. - они тоже должны перенаправляться на FireDAC. Чтобы не менять (или почти не менять) программный код приложения (там более 200 форм) - но чтобы при этом перевести его на FireDAC.
Есть ли какое-нибудь готовое решение для этого или идея бесперспективная? Занимался ли кто-нибудь подобным? Как лучше всего безболезненно перевести проект с IBX на FireDAC?
Переход на другую библиотеку компонентов не поможет. Максимум позволит увеличить производительность в пару раз. На практике эту будет выглядеть так. Сейчас пользователь жмёт кнопку и ждёт 5 минут реакции от программы (программа, к примеру, выполняет построчную обработку записей из таблицы, состоящей из 10000 записей, для каждой записи выполняется отдельный запрос к БД). После перехода на другую библиотеку время сократится до 2.5 минут. Но это всё равно недопустимо долго! За это время оператор пять раз успеет компьютер отресетить.
Варианты решения проблемы:
1) работать в режиме RDP. С этом случае на терминалом сервере Windows может быть запущено множество экземпляров программы под учётными записями пользователей. Базу данных можно разместить на том же либо на соседнем сервере. Проблемы с подключением оборудования (и пробросом его на рабочие места операторов) так или иначе решаются.
2) вводить дополнительный сервер, общаться с ним, например с помощью rest-запросов (например, с передачей json-пакетов). В одном rest-запросе можно запросить сразу несколько таблиц. Использовать для наиболее критических участков программы.
3) переделывать наиболее критические участки (циклическая обработка большого количества записей таблицы) на хранимые процедуры либо EXETUTE BLOCK
4) выполнять длительный код в дополнительном потоке, при этом пользователю можно вешать модальное окно с сообщением "подождите пару секунд..." и какой-нибудь анимацией. Быстрее оно от этого работать не будет, но хотя бы не будут зависать окна программы.
5) кэшировать справочники в памяти программы, периодически читая последние изменения из БД.
