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

Сложно назвать точный год. Пусть это будет 2010. DOS-овских приложений нет, с DBF-ами не работают. Работают с базами, в которых основной инструмент выборки – SQL-строка.
Но писать эти SQL-строки можно по разному и в разных местах. Есть достаточное количество людей, которые по разным причинам пишут эти длинные строки в программных текстах (в несколько строк с кавычками, что очень неудобно при написании) и отправляют эти тексты серверам на выполнение.
Такие люди есть. Их много. Те, кто пишут сервера, должны это как-то учитывать. Они и учитывают, как-то меняя сервера, чтобы они побыстрее выбирали данные такими строками. В результате появляются условия, при которых можно так работать не сильно замедляя процесс.
В десятых годах (условно!) появляются пользователи – машины, которые сами генерируют эти сложные SQL-строки. В инструментах, упрощающих программирование, это было очень давно.  Никто строки руками не писал, все вытаскивали нужные таблицы мышкой, добавляли связи, выбирали поля, получали готовые строки. Но строки эти потом засовывали в программные тексты руками.
А пользователи – машины это, например, 1C c 8.2 версии. Его внутренний SQL на русском языке. Для сервера он свою строку переводит на английский.
С точки зрения быстродействия 1С – плохое решение, потому что работает с данными только SQL строками, а использовать хранимые процедуры не умеет.
Но в 1С есть логическая надстройка надо данными, называемая «регистры». В них хранятся суммы за день, месяц и год. Если надо просуммировать какие-нибудь платёжки за несколько лет, не нужно суммировать исходные данные, можно взять суммы по годам из этих регистров. Не важно, что там и как. Важно, что к вопросу быстродействия разработчики 1С подошли серьезнее всех остальных, хоть и с другой стороны. Потому можно смириться с отсутствием хранимых процедур и (как следствие) иногда к возврату методов программирования DOS-а (правда, уже все в массивах огромной оперативной памяти современных машин, потому быстро).
А вот базу по смертности я не стала совать в 1С. Во-первых, объем такой, что её сложно туда засунуть. Во-вторых, тот же объем вызывает подозрение, что надо использовать хранимые процедуры сервера иначе будет слишком медленно. В-третьих, тот же объем [прочие технические причины].
Вторая пользователь – машина, которая генерирует SQL строки появилась в 2015-м (что ли?) году. Это MVC. Там много чего, включая ту самую надстройку над SQL-строками. Т.е программист пишет некий текст, по которому генерируется SQL строка. Можно вспомнить, что SQL-строка – надстройка над таблицами. Вот только писать её проще. Видимо решили сделать инструмент, с помощью который проще писать SQL-строки (что-то позволяющее уйти от длинных строк в кавычках).
Если что-то появляется, значит на это есть массовый запрос. Или есть предположение, что на это есть массовый запрос. Массовый бухгалтер середины 90-х хотел Excel. Он его и получил. Excel-я оказалось мало, потому он получил ещё упрощённый вариант базы данных – Access.
MVC позволяет очень быстро получить простой сайт, который работает с какой-то базой данных. Т.е потенциальный пользователь – Web дизайнер, которому надо выводить на сайте список товаров с описаниями и ценами.
Идея понятна… Инструмент плохой. Я не зря подробно описываю экономиста с Access-ом. Это тоже упрощённый непрофессиональный уровень. Но то было сделано хорошо, а это сделано плохо.
Надо пояснить про «плохо». В MVC просто писать простое. Минимально сложное -сложно (сложнее, чем работать с SQL-строками).  Ещё более сложное невозможно. Т.е Access не ставил ограничений сложности (только чуть прятал их от неопытных пользователей), а эта штука ставит.  
С другой стороны, сайтам магазинов больше и не надо. Их запросы по работе с данными от поиска по подстроке:
https://www.radetali.ru/

до поиска по комбинации характеристик:
https://www.chipdip.ru/

Складские остатки не всегда соответствуют факту, что явно указывает на то, что учёт отдельно, а сайт отдельно (остатки сайта могут обновляться раз в день или ночь).
Т.е Интернет-пользователь не может вызвать развитие баз данных, ему более чем достаточно того, что есть.
Отсутствие развития можно было бы списать на специфику пользователя. Но настораживает происходящее с 1С. У них был переход с того самого «толстого клиента» на «тонкий» (с DOS на клиент-сервер), но они его так и не доделали. Я даже версию 8.4 ставила, надеясь что они, наконец, сделали масштабирование карт. Нету. Такое ощущение, что в конце нулевых был скачок развития. Что тогда успели, то успели. А дальше остановка.
У некоторых болезней страшное название. Не хочется его произносить. Но происходящее заставляет предположить, что бездарность пришла на смену таланту. Ей надо что-то есть, потому она должна что-то делать. Вот только ничего нового, полезного интересного она не делает. Старое лучше. Или не хуже.    
Из-за всего описанного возникает вопрос: Кто те люди, которые в начале 2024 года способны написать аналог SQL-сервера? С его быстродействием и набором возможностей? Я допускаю, что я знаю не всё. Что где-то есть что-то. И кто-то. Но я знаю, основную проблему баз данных. Это медленная работа при больших размерах базы. Если есть инструмент, способный быстро обрабатывать данные по смертности, его можно использовать. Если его нет… это другая ситуация. И её надо учитывать. К тому же, ничего такого уж страшного нет. Старое работает и очень хорошо работает. На лучшее можно заменить (если доказано, что это лучше). На худшее не надо, даже если оно новое.