База по смертности для тестирования (1)

Информацию обрабатывает сервер базы данных. Хороший сервер должен быстро обрабатывать массив данных такого размера на машине условного 2010-го года выпуска. База большая, но очень простая по структуре (потому так удобна для тестирования). В ней несколько тех самых таблиц с очень большим количеством записей. Вот их информация и должна быстро выбираться и суммироваться. Быстро это вывод данных не больше чем за секунду.
Программы есть разные. Для разных сред и задач. Например, Си-диалект Arduino и его оболочка больше всего похож на Турбо Си 1991-го, что ли, года выпуска. И это хорошо. Во-первых, 10 дет назад для микроконтроллеров был только ассемблер. Во-вторых, что-то другое нужно для больших проектов, которые не влезут в маленькую память микроконтроллера. Т.е имеющийся инструмент подходит к задаче.   
Сервер это инструмент обработки таблиц с данными. Реально их только два. Это MS-SQL-Server и Interbase (от фирмы Borland). Конечно, их больше. Если очень надо, можно написать какое-то хранилище таблиц и интерпретатор SQL-строк. Они есть. Для смартфонов, например, есть отдельная база. MS-Access сам по себе это умеет. Oracle можно вспомнить, который появился в 80-х, которого никто не видел, но спецкурс по SQL строкам в университете (в классе с доской) был именно про него.
Так вот. Interbase, как бы он ни назывался, написан в условном 1995 году. По сути это ещё DOS-овское продолжение. Тогда это было очень круто. У всех появилась возможность сделать себе домашнюю бухгалтерию или что-то другое, используя те самые SQL строки (а не DBF файлы, нормальные для того момента). Проблема в том, что начиная с некого объема данных, там начинает медленно работать вообще все. А этот объем это чуть больше той самой домашней бухгалтерии с 100 строками в год.
Но дело даже не в продуктах фирмы Borland, а в том, что реально большая база позволяет проверить любой сервер. Работает быстро? Значит, хороший, сервер. Медленно? Значит, плохой.
Просто для иллюстрации. База с данными по нескольким отчетам (форма 121, 130 и т.д). Правда, по всей Ленинградской области. Это очень мало по меркам баз данных. В ней, естественно есть список учреждений. Не помню, что мне потребовалось поменять. В каком-то поле этого списка учреждений заменить ноль на единицу. Привычно ввожу строку «UPDATE sUch SET fld1=1». У меня этот запрос минут 10 работал. Я решила, что машина повисла. А это та самая медленная работа вообще всего, начиная с некоторого объема базы. Сама бы не видела – не поверила бы. Это низкое качество уровня муляжа фонарика. Но и такое бывает. 
Поэтому лучше просто проверить то, что притащат любые люди с горящими глазами.
Есть ещё одна неприятная вещь. Технологическая вершина в обработке больших объемов данных это нулевые. В десятых, если смотреть с этой стороны, началась деградация. У того, что я назвала деградацией, есть, как ни странно, плюсы. Но размер данных такой, что база написана по технологиям нулевых (т.е самый быстрый вариант). Нормальный сервер должен позволять делать и такие вещи.
А теперь чуть подробнее. Раньше вся информация хранилась в отдельных текстовых файлах. Пусть есть список людей с фамилиями, именами, отчествами и датами рождения. На имена пусть зарезервировано место по 20 букв, а на дату хватит 12.45.7890 = 10 букв. Значит, на строку о человеке потребуется 20*3+10=70 букв. Значит, чтобы получить данные о 10-м человеке в списке надо открыть текстовый файл, переместиться от начала на 70*10=700 букв и прочитать 70 букв. Потом это можно разделить на фамилию, дату и т.д.
Таким образом структурированные текстовые файлы с информацией имели расширение DBF. Работали с ними системы Clipper и FoxPro. Эти системы позволяли читать и записывать данные.
Чтобы получить более сложные вещи, например кассовый остаток по приходам и расходам, надо было прочитать и просуммировать в программном цикле все приходы, и вычесть из них все расходы.  
Так работал DOS. Он позволял читать файлы через «окно» и записывать в них. Причем «окно» считываемой информации было небольшое, потому что у DOS-а было (по современным меркам) очень мало оперативной памяти.
Скорее всего, какие-то те ограничения просочились в Interbese, который был написан, в момент перехода от DOS к Windows, потому он так медленно и работает. Полноценные сервера под Windows используют всю память (которой теперь много).  
«Толстый клиент 1C» это тоже, по сути, DOS-овский вариант работы с информацией. Это может быть не очень плохо, если нужно только одному пользователю на одной машине. Это начинает очень медленно работать, когда этим надо пользоваться через сеть. Проблема решается «удалёнными рабочими столами» а не полноценной сетевой работой.
Чего-то я забралась в дебри. Надо их как-то упорядочить.
DOS-овская работа с файлами плохо. Сервер базы данных и клиентское приложение, запрашивающий с сервера информацию, хорошо.
Медленно работающий сервер – плохо (чем бы это ни было вызвано).
С этими утверждениями вряд ли кто будет спорить. Это так с условного 2000-го года.
Дальше интереснее и неоднозначнее. Имеется в том же 2000-м году некий экономист Миша, которому просто надо отслеживать хозяйственную деятельность. И все ему неудобно. 1С до 8.2 версии 2009-го года был крайне неоднозначен. И официальный план счетов, рассчитанный на одну фирму, его не устраивает. У него этих фирм 20 и надо считать какие-то итоги по их общей деятельности. 
Именно такому Мише даётся Excel, которого тоже мало. Можно на странице формулой посчитать кассовый остаток, последовательно внося приходы и расходы. А вот подотчёты в Ecxel-е закрывать уже неудобно.
А в базе данных это все сделать можно. Потому ещё такой Миша получает Access с кучей возможностей что-то сделать без программирования или с очень простым программированием.  И многие не программисты что-то себе делали и использовали.
Внимание вопрос: Что лучше? Упрощённый вариант базы, с которой справится средний Миша или полноценный сервер с кучей возможностей и хорошим быстродействием?
Правильный ответ: Вопрос дурацкий. Нужно и то и другое и возможность объединения. Это все и есть. Если возможность подключать Access к серверу. Есть возможность писать и там и там сложные программы.
Тут важно, что быстродействие может быть не так важно как простота использования, позволяющая увеличить количество пользователей.
В нулевые годы на площадке имеются:
1] Опытный пользователь экономист Миша, что-то себе сооружающий с помощью интерфейса.
2] Я, т.е программист полностью перешедший на работу с SQL строками и предпочитающий писать их там, где надо (т.е в сервере). Клиент – серверная работа предполагает, что клиентское приложение запрашивает какую-то информацию  (вызывает хранимую процедуру с параметрами), а сервер внутри себя все выбирает и передаёт клиенту только нужное (так меньше нагрузка на сеть).
3] Программист X, пишущий SQL строки, но дальше работающий так, как работал в DOS-е. Опять же, живьём видела. Он первой SQL-строкой выбирал условные кассовые приходы, второй расходы, а потом в тексте клиента все это суммировал. Ещё гордился тем, что у него такой быстрый низкий уровень типа ассемблера.
С №3 тихо боролись все нулевые. Но, с другой стороны, отправка на сервер SQL строки выборки (вместо имени хранимой процедуры и параметров) не всегда клиника. Иногда так проще. Иногда иначе никак. Все определяется тем, насколько быстро сервер выполнит этот запрос и вернёт нужную информацию. Сервер – штука умная. Он смотрит, что у него запрашивали; и на для часто запрашиваемого, похоже, формирует внутренние сценарии, ускоряющие процесс.