Файловые и клиент-серверные базы данных

С файлами работали DOS-овские программы. Основными тогда были Clipper и FoxPro. Оба открывали информацию, хранящуюся в файлах DBF и что-то с ней делали. Никаких SQL строк не было. Было «открыть файл», при наличии индекса «найти строку» и, конечно, прочитать или записать информацию. Можно было что-то делать читая строку за строкой (например, суммировать какую-то цифру или выводить строки на экран).
В районе 2000-го года начался массовый переход на Windows и выборку через SQL-строки. А в стране огромное количество работающих программистов, которые привыкли работать так, как они работают. Кому-то переучиваться легко, кому-то трудно. А уж то, чем это сопровождается на словах и особенно в текстах иногда совсем… печально. Общалась, например, со своим ровесником, который выбирал информацию SQL-строкой (выбрать всё), а потом работал с выборкой как раньше с файлом. Объяснял это тем, что у него такое «низкоуровневое программирования» (вроде быстрого ассемблера вместо медленного Си) и его выборки работают быстрее чем SQL-строки.
Некоторая болезненность в вопросе, что и чем выбирать вызвана, скорее всего, этой историей.
Надо, наверное, четко сформулировать, что тут является рациональным. У врачей «не навреди», у программистов «не нагружай технику». Пусть она работает всё быстрее и быстрее, отход от этого принципа имеет достаточно шансов положить и машину и сеть.
Клиент – серверное приложение это приложение, в котором клиент получает минимум информации (т.е сеть не засоряется передачей больших объемов данных) и сам ничего не делает (вся обработка информации идет на возможно более мощной машине – сервере). Поскольку сервер работает со своей информацией на своей машине, у него всё обрабатывается максимально быстро. После обработки всё те  же просуммированные платёжки передаются в виде, например, пяти самых больших сумм по плательщикам. 5*100 байт на названия организаций + 5*16 байт – суммы. Вот и вся нагрузка на сеть.
Сюда же добавлю что 1С до 7 включительно работает на той самой файловой системе («толстый клиент», «управляемые формы») . Потому в сети на нём работать невозможно, хоть какой-то вариант – рабочий стол на машине с базой.
Теперь про то, что делается у меня. Вообще-то ничего особо страшного у меня не делается. SQL-строками я всё равно суммы выбираю, а то, что я их не PIVOT-ом совмещаю, а средствами Access-а – не очень это страшно на таких объемах.
Довольно скользким моментом является передача всех контрактов по учреждению. Их может быть до 500 штук.
С ними всё совсем неприятно потому что, повторюсь, в контрактах с РНК нет части кодов и их надо вытащить из платёжек. Вообще-то в SQL строку можно вписать другую SQL строку для выборки информации по полю, что-то типа:
SELECT tab1.fld1,
(SELECT tab2.fld3 FROM tab2 WHERE tab2.ID=tab1.ID_in_tab2)
FROM tab1
.. ..но группировать по такому от отказался (видимо посчитав что написано уже какой-то программное извращение). К тому же у меня таких кодов три (раздел, целевая статья, вид расходов).
Выбрать это можно только программированием на сервере с использование курсора, т.е программного цикла по информации, т.е так это надо было бы написать в хранимой процедуре (которую я создать в той базе не могу):

Т.е в курсор вытаскиваются все контракты конкретного учреждения, а дальше едёт цикл по этим записям.
Полный текст:
https://drive.google.com/file/d/1pDwU-6W67I4FTgI-80bIJzfe7S_0eQd5/view?usp=sharing

ID учреждения это вот это:

В Access-овском клиенте у меня делается то же самое:

В rstData у меня загружен список контрактов. На каждой строке выполняется поиск недостающих кодов (rxtZFR). Только в хранимой процедуре всё бы обработалось и что особо важно, просуммировалось бы ещё на сервере (в тексте возвращается дополненный список с РНК только для наглядности), а клиенту был бы послан минимум информации. Здесь же клиент сам разбирается с полым списком договоров. Но с одной стороны договоров не очень много (100-500 штук), с другой прочие варианты усложнили бы конструкцию. Если бы мне потребовалось так гнать с сервера платёжки, которых намного больше, я бы решила что так делать нельзя (а с малым количеством договоров можно).

Интересно что в следующей версии… клиентов (не Access a Интернет, не ADODB a ADO.NET) расширен инструментарий работы с информацией на локальной машине. Немного против клиент-серверной логики но видимо много кому потребовалось.   
А на 1С работа через «Таблицы Значений» (или как их там зовут?)  вообще стандарт работы. Это и перевесило моё настороженное отношение к такому методу.