ЗимарглПробегала статья сравнения трафика постгрес с ораклом. Что разница в трафике вдвое.

Погуглил, похоже в mssql компрессии TDS нет. Хм.
Трафик нужно сравнивать cколько на одну ODBC / JDBC инструкцию будет round-trip'ов. Собственно "байты" достаточно пофиг.

Тот же Oracle, до версии 11 не умел делать array fetch / bulk fetch с полями типа Blob. Т.ч. стоило бы в запросе появится Blob'полю или любому производному от него (например гео-данные) - тормоза по сети были бы обеспечены.

Т.ч. IMHO для задачи топикстартера, если канал реально никак не расширить - то одно из:
1) решения на базе аппликейшен сервера
В крайнем случае, можно посмотреть есть ли поддержка RPC /remote procedure call/ в Delphi и сделать свой "сервер". Разделить проект на две части - серверная, клиентская. И общаться через какой-то механизм взаимодействия
2) терминальные решения
3) что-то "смешанное". Например Oracle Forms при работе в режиме Web-Forms работает фактически как терминальный сервер. Отсылает туда-обратно нажатия клавиш и информацию которую нужно обновить на экране.

IMHO На каналах с большой задержкой - все протоколы работающие с БД скорее всего пойдут лесом. А, подозреваю, а автора задержки на канале будут из разряда "тушите свет".

В начале 2000-х занимался оптимизацией для Oracle Forms.

Очень радовало, полное не совпадение данных по моем тестам и то, что было указано в нотах/инструкциях Oracle для Oracle Forms разработчиков. Например, их тесты которые якобы считали round trip'ы, считали совершенно другое. И с round-trip'ами на канале не совпадали, чуть более, чем полностью. Т.е. те советы которые давали ноты/примеры для Oracle Forms по оптимизации - делали хуже, чем стандартное поведение.

maytonТема жадных Блобов заинтересовала. Еще лет 10 назад у меня была мысль мелкие
блобы складывать в VARCHAR2(4000 bytes) в кодировке BASE64 той-же data-row при условии что размер
подходит (не больше кодированной строки).
А нафига? У Oracle есть RAW, правда не уверен, может ли он быть переменного размера. Скорее всего может.
maytonРазумеется моя оптимизация базировалсь на предположении что 80-90% блобов будут мелкие.

Но сектор разработки тогда не поддержал мою идею. Хотя проблемы на канале были (ASDL модем между филиалами).
У нас не так много было BLOB'ов.

Но зато часто было обращение к настроечным справочникам, которые не меняются

Т.ч. сделал механизм кэширования справочников на клиенте (просто свою реализацию вместо/поверх CREATE_RECORD_GROUP_WITH_QUERY) - на канале 32 Kbit ADSL все залетало.

Но на радио-канале с задержками до 0.5 - 1 sec. - тушите свет. Читал доки от оборудования (провайдер прислал доки на их базовые станции) откуда берутся такой разброс в задержках, даже не понял. Но так как провайдер, понятное дело, ради нас настраивать QoS (quality of service) отказался, то делать было нечего. Поставили Windows терминальный сервер - он не так с задержкам критичен, хотя ряд модулей пришлось доделывать (например работу с изображениями, т.к. он терминал тогда только 256 цветов давал).

Я не про Long raw, а про просто Raw. Т.е. извращение с base64 и Varchar2 не нужно.