Здравствуйте, alex_public, Вы писали:
_>Кстати, ты в курсе языка запросов в MongoDB? Что скажешь про его возможность работы с произвольным кодом?
Посмотрел. Не очень впечатлился: там, по большому счёту, SQL с другим синтаксисом. Вот, скажем, та самая задачка с "предикатом зависящим от предыдущего элемента" на монге непонятно как решается. Похоже, никак — опять же, потому, что нет понятия "порядок документов".

Здравствуйте, IT, Вы писали:

_>>Не совсем. Мы обсуждаем чем бы таким более эффективным заменить SQL в реляционных СУБД. И в этом смысле вполне можно в качестве вдохновения полистать различные вариации реализации запросов во множестве популярных nosql СУБД.
IT>Видимо у меня проблемы с восприятием такой логики. Мы обсуждаем замену языка запросов в реляционных СУБД, поэтому давайте обсудим замену самих реляционных СУБД. Это как?

Странно что у тебя проблемы с пониманием очевидной логики. Или может просто с прочтением моих сообщений?))) Где ты увидел про замену РСУБД?

Да, отказ от sql в этих новых СУБД изначально являлся следствием их принципиально другого внутреннего устройства. Однако это одновременно "освободило" их от исторического наследия, позволив проявлять любую фантазию. В том числе и в тех областях, которые применимы и в РСУБД, а не только в каком-нибудь MapReduce. И я не вижу ничего плохого в том, чтобы современные РСУБД вдохновлялись этими разработками. Собственно это и так происходит последние годы, но исключительно в аддитивном эволюционном режиме (типа а добавим ка мы в нашу СУБД sql функции для работы с json/xml и т.п.). Но никто не мешает задуматься о революционном изменение (типа замены sql на что-то более приличное).

Здравствуйте, Sinclair, Вы писали:

S>Ух ты! Резкий поворот: только что мы говорили о выразительности и объёме кода, как вдруг перешли к производительности.
S>Да, это правда — в дотнете с оптимизацией всё не очень хорошо. Но в этом виноват не Linq — как раз он-то делает всё, что можно, чтобы помочь оптимизатору.
S>Основная затычка — невозможность инлайнить делегаты, в которые превращается код на linq to objects.
S>Если бы были инлайны — то и копирования можно было бы устранить, т.к. результирующий выхлоп был бы эквивалентен "тупому императивному аналогу".

Не был бы. Потому что правильный императивный код не делал бы не то что копирований, но и даже повторных обращений по предыдущему индексу. Правильный код считал бы всё касающееся конкретной строчке на соответствующей ей итерации цикла, оставляя результат вычисления (например результат count или вообще булев флаг — это уже по вкусу) для следующей итерации во внешней к циклу "глобальной" мутабельной переменной. Именно использование таких вещей, родных для процессора, но противоречащих функциональной парадигме и является характерным признаком императивного кода.

_>>Наверняка там простейшее прямое обращение к данным, в классическом императивном стиле. Собственно иначе и быть не может (и даже не из-за производительности), т.к. lag можно задать динамическое смещение (как и в императивном коде).
S>Не всё так просто. С учётом того, что исполнительный механизм работает с "перечисляемыми" источниками, которые умеют делать только GetNext() (то есть эквивалентны IEnumerator из дотнета), и не умеют GetRecordNumber(x), то скорее всего там внутри делается скользящий буфер, в случае одиночного смещения превращающийся в ту самую пару значений.

Тогда у тебя всегда должен быть скользящий буфер размером со всю таблицу, потому как функция lag допускает передачу в качестве параметра смещения произвольного значения (т.е. например из какого-то столбца).

Здравствуйте, Sinclair, Вы писали:

_>>Ну если ты так считаешь, то конечно же легко сможешь привести хотя бы один пример, в котором работа с коллекциями на базе Linq будет более быстродействующей, чем произвольный императивный код? )
S>Отож. Познакомьтесь с i4o.
S>Внезапно исполнитель автоматически опознаёт наличие индекса, и вместо O(N) получаем O(log(N)) быстродействие.
S>В случае "произвольного императивного кода" придётся идти и переписывать все места, где этот произвольный императивный код итерируется по нашей коллекции.

Правильно. Но так после переписывания данный императивный код всё равно же будет быстрее чем эта поделка. Т.е. это ты привёл пример на совершенно другую тему (по поводу модульности, рефакторинга и т.п.), и он не является ответом на мой вопрос.

Оффтопик: твоя фраза насчёт O(N)/O(log(N)) на порядки корректнее бреда про тысячи раз в их описание. Я в начале сразу открыл ссылку и прочитав их бред про тысячи раз посмеялся, сразу подумав про данную формулу (значение которой может быть и миллионами раз и меньше 1), а потом уже увидел ту же корректную мысль в твоём письме дальше. )))

_>>Это не так. Произвольные функции можно задавать как в MapReduce, так и в выражение where. Собственно единственный пример в документации к where https://docs.mongodb.com/manual/reference/operator/query/where/ как раз это демонстрирует.
S>Отличный пример. А есть пример, в котором все терабайты JSON не просасываются через память и медленную функцию вычисления md5 в поисках нужного?
S>Иначе внезапно окажется, что один инстанс SQL Server Express на моём ноуте переплюнет по производительности Монгу на кластере из 24х PowerEdge 900.
S>Потому, что запрос
S>

S>select * from users where HASHBYTES('MD5', name) == 0x9b53e667f30cd329dca1ec9e6a83e994
S>

S>В отличие от Монги использует индекс

Не очень понял к чему ты это написал. Я же думаю, что ты прекрасно в курсе того, что в MongoDB есть произвольные индексы (помимо базового ключа). Однако далеко не всё можно считать только на индексах.

Здравствуйте, IB, Вы писали:

_>>Ну если ты так считаешь, то конечно же легко сможешь привести хотя бы один пример, в котором работа с коллекциями на базе Linq будет более быстродействующей, чем произвольный императивный код? )
IB>Ну не надо передергивать, тут ловкий переход от for к произвольному императивному коду. =)

Я вообще то всё время писал именно про императивный код. А for — это всего лишь его пример. И да, в случае работы с коллекциями без for естественно не обойтись. Собственно он и внутри любого выражения linq сидит. Только там он существенно ограничен.

IB>По поводу универсальности, как я понимаю, возражений нет? Этот вопрос закрыли? )

По поводу универсальности чего? Если речь про работу с коллекциями в стиле sql/linq, то очевидно же, что там есть существенные ограничения. Их конечно же можно пытаться обходить с помощью различных костылей, но от этого они не перестанут быть врождёнными уродствами.

_>>Ну если бы можно было описывать любые возможные результаты, то тогда конечно. Но это явно речь не про SQL.
IB>Да, здесь речь скорее про linq, если мы говорим про языки общего назначения. Однако и SQL в своей предметной области таки позволяет описать любые возможные результаты.

Ну если в стиле секса в гамаке, то возможно. А по нормальному (читай по удобному) в sql доступно только определённое подмножество задач работы с коллекциями.

_>>Мы же обсуждаем именно их, а не внешнюю красоту (тем более, что сейчас многие предпочитаю прятать этот промежуточный язык за встраиваемыми DSL'ми).
IB>Это не внешняя красота, а удобство использования. А уж если прятать за DSL-ем, то тогда вообще не понятно причем тут язык, так как за тем же DSL-ем вполне можно спрятать и SQL, ровно с тем же эффектом.

Если бы SQL мог передать всё (как это может например произвольный императивный код), то конечно. А так у нас DSL ограничен этим промежуточным языком,

_>>Это не так. Произвольные функции можно задавать как в MapReduce, так и в выражение where. Собственно единственный пример в документации к where https://docs.mongodb.com/manual/reference/operator/query/where/ как раз это демонстрирует.
IB>Вооот, читаем документацию внимательно: The $where provides greater flexibility, but requires that the database processes the JavaScript expression or function for each document in the collection.
IB>Иными словами, никаких чудес нет, уныло идем по всей коллекции и применяем нашу лямбду. То есть, это полностью эквивалентно SQL запросу + прикладному коду по результатам, с точностью до синтаксиса (для сиквела, например, можно написать хранимку на .Net/C++ если что, с тем же эффектом).

И? Никто тут про какие-то чудеса не говорил. Речь шла про недоступное для SQL. И указанное является недоступным ("хранимка на .Net/C++" — это уже не SQL).

IB>Так что это точно так же отностится к классу "внешней красоты" по твоей терминологии, то бишь чисто синтаксический сахар.

Т.е. ты можешь на SQL записать произвольный императивный код? )))

Здравствуйте, IB, Вы писали:

_>>Ну почему же, различных nosql систем сейчас множество, популярность их только растёт и у каждой из них обычно своя вариация на тему запросов (в том числе и частенько в виде императивного языка).
IB>Роста популярности nosql уже давно нет, народ наигрался и переписывает все обратно на сиквел.Лучшие из nosql переквалифицировались в распределенный кэш, остальный медленно чахнут не успев взлететь.

Распределённый кэш — это изначальная функция некоторых nosql СУБД, типа Redis. Но та же MongoDB или Cassandra явно не относятся к кэшам, однако прекрасно чувствуют себя на рынке.

Причём в последнее время можно увидеть уже и такие https://www.ibm.com/communities/analytics/riskmanagement-blog/big-data-for-banking-which-database-model-is-best-for-you/ статьи — дело дошло даже до таких матёрых консерваторов, как банки.

IB>Относительно же их языка запросов — полна печаль, в лучшем случае они цельно тянуты из какой-нибудь более-менее толковой ORM. Хуже того, к большинству nosql баз стали судорожно прикручивать аналоги SQL, так как что-то эти императивно-объектные языки хапросов не очень справляются, как только коллекцый больше чем одна и надо проекцию построить.

Ну так в SQL конечно же тоже есть много полезного — совершенно логично взять всё лучшее и из него тоже. Но это не значит, что надо ограничиваться его концепцией.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, alex_public, Вы писали:
_>>Кстати, ты в курсе языка запросов в MongoDB? Что скажешь про его возможность работы с произвольным кодом?
S>Посмотрел. Не очень впечатлился: там, по большому счёту, SQL с другим синтаксисом.

Так SQL тоже позволяет произвольный императивный код, глобальные переменные и т.п.?)))

S>Вот, скажем, та самая задачка с "предикатом зависящим от предыдущего элемента" на монге непонятно как решается. Похоже, никак — опять же, потому, что нет понятия "порядок документов".

Вообще то можешь спокойно по о ключу упорядочить и внутри документа (как массив). Ты кстати сюда https://docs.mongodb.com/manual/meta/aggregation-quick-reference/ заглядывал? )

Здравствуйте, alex_public, Вы писали:

_>Правильно. Но так после переписывания данный императивный код всё равно же будет быстрее чем эта поделка. Т.е. это ты привёл пример на совершенно другую тему (по поводу модульности, рефакторинга и т.п.), и он не является ответом на мой вопрос.
Тут я потерял нить рассуждений. Речь идёт, в первую очередь, о выразительности. Мы пишем понятный код, который ещё и быстро работает.
Можно заменить его на императивный код, но мы рискуем проиграть в понятности и поддерживаемости.

_>Оффтопик: твоя фраза насчёт O(N)/O(log(N)) на порядки корректнее бреда про тысячи раз в их описание.
У них раньше кроме описания были ещё и замеры производительности. Там выигрышь начинался на каких-то семечках вроде сотни элементов.

_>Не очень понял к чему ты это написал.
К тому, что $where медленно и печально перебирает всю коллекцию. Судя по их документации.
А SQL Server ровно приведённый запрос может оптимизировать автоматически. Не переписанный вручную с хинтами, не курсор с перебором нужного индекса, а вот прямо так написанный неэффективный код, выполняющий поиск по md5 от юзернейма.
Ведь эти все трюки с индексами в SQL были придуманы не просто так.
Они как раз позволяют взять приложение, и спроектировать его понятным.
А уже потом, с учётом накопленной статистики использования, тюнить производительность. А не переделывать структуру объектов каждый раз, как план запроса окажется неоптимальным.

Здравствуйте, alex_public, Вы писали:

_>Так SQL тоже позволяет произвольный императивный код, глобальные переменные и т.п.?)))
Насчёт произвольности, по-моему, преувеличение. Вон там список ограничений на аргументы MapReduce удивительно напоминает ограничения на custom aggregate в SQL Server.
Чудес-то не бывает.

S>>Вот, скажем, та самая задачка с "предикатом зависящим от предыдущего элемента" на монге непонятно как решается. Похоже, никак — опять же, потому, что нет понятия "порядок документов".

_>Вообще то можешь спокойно по о ключу упорядочить и внутри документа (как массив). Ты кстати сюда https://docs.mongodb.com/manual/meta/aggregation-quick-reference/ заглядывал? )
Заглядывал. Если честно, то не очень понял, что там к чему.
Непонятно, что относится к массивам, а что — к коллекциям документов.
Ну, то есть я могу ошибаться — наверное, нетрудно будет написать запрос, который выполняет обсуждаемую операцию, на монговом языке?

Здравствуйте, alex_public, Вы писали:

_>Не был бы. Потому что правильный императивный код не делал бы не то что копирований, но и даже повторных обращений по предыдущему индексу. Правильный код считал бы всё касающееся конкретной строчке на соответствующей ей итерации цикла, оставляя результат вычисления (например результат count или вообще булев флаг — это уже по вкусу) для следующей итерации во внешней к циклу "глобальной" мутабельной переменной.
Ну так это и есть копирование. "Глобальность" переменной нам вообще неинтересна. В приведённом примере prev и есть эта глобальная переменная.
Если у меня к "текущей" и "предыдущей" позициям применяются разные операции, то код одинаков с точностью до порядка вычисления:

currItem = a[i++];
x = SumSquares(prevItem);
y = Sum(currItem)
prevItem = currItem;

против

currItem = a[i++];
y = Sum(currItem)
x = SumSquares(currItem);
prevItem = currItem;

Если же хитрость — в том, что там одна и та же операция (например, count), то мне никто не помешает сделать аналогичный PairScan не по исходной коллекции, а по результату вычисления count.
И опять у меня будет ровно такой же цикл, как и в "произвольном императивном коде":

currItem = a[i++];
y = count(currItem);
prevY = y

_>Именно использование таких вещей, родных для процессора, но противоречащих функциональной парадигме и является характерным признаком императивного кода.
Родными для процессора являются вещи, достаточно далёкие от "произвольного императивного кода", если под ним подразумевать С++.

_>>>Наверняка там простейшее прямое обращение к данным, в классическом императивном стиле. Собственно иначе и быть не может (и даже не из-за производительности), т.к. lag можно задать динамическое смещение (как и в императивном коде).
S>>Не всё так просто. С учётом того, что исполнительный механизм работает с "перечисляемыми" источниками, которые умеют делать только GetNext() (то есть эквивалентны IEnumerator из дотнета), и не умеют GetRecordNumber(x), то скорее всего там внутри делается скользящий буфер, в случае одиночного смещения превращающийся в ту самую пару значений.

_>Тогда у тебя всегда должен быть скользящий буфер размером со всю таблицу, потому как функция lag допускает передачу в качестве параметра смещения произвольного значения (т.е. например из какого-то столбца).
Интересно. Надо бы посмотреть — я перестал плотно работать с SQL Server задолго до того, как в нём реализовали эту функцию.

Здравствуйте, alex_public, Вы писали:

_>Т.е. ты можешь на SQL записать произвольный императивный код? )))
Да почему нет-то?
Просто этот "произвольный императивный код" будет адски неэффективным. То, что вы ищете, называется "курсоры". Их очень любят люди, которые мыслят категориями "ну вот мы взяли текущую запись, пощитали, потом взяли следующую" и т.п.
Внезапно оказывается, что "ограниченный декларативный код" в заданной нами среде (ACID, OLTP) внезапно выполняется быстрее, чем вот такой императивный.
А если потребовать от "произвольного императивного кода" реализовать хотя бы пару-тройку плюшек, доступных в SQL за полчаса (типа партишнинг / удалённые сервера, не говоря уже о добавлении индексов), то там только время компиляции проекта превысит расходы времени DBA.

Здравствуйте, alex_public, Вы писали:

_>Но никто не мешает задуматься о революционном изменение (типа замены sql на что-то более приличное).

Бред какой-то А чем тебя SQL не устраивает? Тем что его написал не ты?

Здравствуйте, IT, Вы писали:

_>>Но никто не мешает задуматься о революционном изменение (типа замены sql на что-то более приличное).
IT>Бред какой-то А чем тебя SQL не устраивает? Тем что его написал не ты?

Эм, предлагаю тебе перечитать всю данную тему с самого начала... ))) Данный вопрос подробно изложен в ней, причём многими людьми.

Здравствуйте, Sinclair, Вы писали:

_>>Правильно. Но так после переписывания данный императивный код всё равно же будет быстрее чем эта поделка. Т.е. это ты привёл пример на совершенно другую тему (по поводу модульности, рефакторинга и т.п.), и он не является ответом на мой вопрос.
S>Тут я потерял нить рассуждений. Речь идёт, в первую очередь, о выразительности. Мы пишем понятный код, который ещё и быстро работает.
S>Можно заменить его на императивный код, но мы рискуем проиграть в понятности и поддерживаемости.

Ты потерял нить рассуждений потому, что здесь ты ответил на мой вопрос другому участнику дискуссии, с которым обсуждалась как раз производительность (он утверждал, что for будет менее производительным чем linq на каких-то коллекциях).

_>>Не очень понял к чему ты это написал.
S>К тому, что $where медленно и печально перебирает всю коллекцию. Судя по их документации.

Так а SQL БД без индекса по данному полю будет работать как-то по другому? )

Здравствуйте, alex_public, Вы писали:

_>Эм, предлагаю тебе перечитать всю данную тему с самого начала... ))) Данный вопрос подробно изложен в ней, причём многими людьми.

Периодически я тратил своё драгоценное время на эти, прости господи, изложения. Ничего интересного ни разу не обнаружил. Идеализм, шапкозакидательство и, чаще всего, непонимание того, что из себя представляет разработка приложений, использующих базы данные.

Здравствуйте, Sinclair, Вы писали:

_>>Так SQL тоже позволяет произвольный императивный код, глобальные переменные и т.п.?)))
S>Насчёт произвольности, по-моему, преувеличение. Вон там список ограничений на аргументы MapReduce удивительно напоминает ограничения на custom aggregate в SQL Server.
S>Чудес-то не бывает.

Ну во-первых тут была речь не про MapReduce (это вообще странно тут привлекать, т.к. у этого дела нет вообще никаких аналогов в мире РСУБД), а про другие возможности использования императивного кода. А во-вторых какое отношение custom aggregate имеет к SQL? )

S>>>Вот, скажем, та самая задачка с "предикатом зависящим от предыдущего элемента" на монге непонятно как решается. Похоже, никак — опять же, потому, что нет понятия "порядок документов".
_>>Вообще то можешь спокойно по о ключу упорядочить и внутри документа (как массив). Ты кстати сюда https://docs.mongodb.com/manual/meta/aggregation-quick-reference/ заглядывал? )
S>Заглядывал. Если честно, то не очень понял, что там к чему.
S>Непонятно, что относится к массивам, а что — к коллекциям документов.
S>Ну, то есть я могу ошибаться — наверное, нетрудно будет написать запрос, который выполняет обсуждаемую операцию, на монговом языке?

Если говорить про ту задачку, что мы обсуждали для коллекций, то мне не очевидно как её сделать и на SQL (т.к. там были "вложенные" коллекции, кстати как раз на MongoDB такое делать проще, т.к. там вложенные структуры — это норма). Если же говорить о самой сути проблемы, которую мы обсуждали и для решения которой в SQL есть функции lag и lead, то для анализа "между документами" в MongoDB ты можешь банально использовать "глобальную" переменную, причём сделать её например массивом по ключу и класть в неё результат условия. Ну а в случае хранения коллекции не как набора документов, а как массива внутри одного документа, то ситуация сводится к банальному JS коду работы с массивом. )))

Здравствуйте, Sinclair, Вы писали:

_>>Не был бы. Потому что правильный императивный код не делал бы не то что копирований, но и даже повторных обращений по предыдущему индексу. Правильный код считал бы всё касающееся конкретной строчке на соответствующей ей итерации цикла, оставляя результат вычисления (например результат count или вообще булев флаг — это уже по вкусу) для следующей итерации во внешней к циклу "глобальной" мутабельной переменной.
S>Ну так это и есть копирование. "Глобальность" переменной нам вообще неинтересна. В приведённом примере prev и есть эта глобальная переменная.
S>Если у меня к "текущей" и "предыдущей" позициям применяются разные операции, то код одинаков с точностью до порядка вычисления:
S>

S>currItem = a[i++];
S>x = SumSquares(prevItem);
S>y = Sum(currItem)
S>prevItem = currItem;
S>

S>против
S>

S>currItem = a[i++];
S>y = Sum(currItem)
S>x = SumSquares(currItem);
S>prevItem = currItem;
S>

S>Если же хитрость — в том, что там одна и та же операция (например, count), то мне никто не помешает сделать аналогичный PairScan не по исходной коллекции, а по результату вычисления count.
S>И опять у меня будет ровно такой же цикл, как и в "произвольном императивном коде":
S>

S>currItem = a[i++];
S>y = count(currItem);
S>prevY = y
S>

Нет, здесь не о том речь. Я здесь говорю про разницу между таким кодом:

for(auto c: col) f(c);
for(auto c: col) g(c);

и таким кодом:

for(auto c: col){
    f(c);
    g(c);
}

Надеюсь не надо объяснять разницу?)

_>>Именно использование таких вещей, родных для процессора, но противоречащих функциональной парадигме и является характерным признаком императивного кода.
S>Родными для процессора являются вещи, достаточно далёкие от "произвольного императивного кода", если под ним подразумевать С++.

Переменная, используемая для агрегации по коллекции, в случае правильного императивного кода превращается в регистр процессора (соседствует с переменной, по которой идёт итерация цикла).

Здравствуйте, Sinclair, Вы писали:

_>>Т.е. ты можешь на SQL записать произвольный императивный код? )))
S>Да почему нет-то?
S>Просто этот "произвольный императивный код" будет адски неэффективным. То, что вы ищете, называется "курсоры". Их очень любят люди, которые мыслят категориями "ну вот мы взяли текущую запись, пощитали, потом взяли следующую" и т.п.

Ты что-то путаешь. Код, использующий курсоры, будет по сути работать на клиенте, используя СУБД как "удалённый" массив. А мы говорим о произвольном коде, но исполняющемся на сервере СУБД. В SQL для этого нет никаких инструментов.

Конечно же есть всяческие императивные pl/sql и его аналоги в других РСУБД, которые как раз и реализуют данную функциональность. Но во-первых это у нас собственно уже не SQL, во-вторых решение довольно костыльное (надо в начале декларировать там что-то и т.п., а не определять императивный код прямо в запросе) и в-третьих я что-то не помню вменяемых DSL/ORM, которые могли бы эффективно задавать (генерируя процедуры и т.п.) такое в наших клиентских языках.

S>Внезапно оказывается, что "ограниченный декларативный код" в заданной нами среде (ACID, OLTP) внезапно выполняется быстрее, чем вот такой императивный.

Ещё раз повторюсь: полноценные индексы есть и в MongoDB. И в случае таких простейших случаев, как запрос прямо по индексу, и у удобство и быстродействие скорее всего не будет существенно отличаться. А вот в более нетривиальных случаях уже надо смотреть детали — я вполне себе могу представить ситуации, где будет выигрыш как одной стороны, так и и другой, в зависимости от типа задачи.

S>А если потребовать от "произвольного императивного кода" реализовать хотя бы пару-тройку плюшек, доступных в SQL за полчаса (типа партишнинг / удалённые сервера, не говоря уже о добавлении индексов), то там только время компиляции проекта превысит расходы времени DBA.

Эм, вот уж как раз про организацию работы по распределённым серверам РСУБД лучше не заикаться — оно тупо не умеет и как раз из-за этого и появилось большинство nosql СУБД.

Здравствуйте, IT, Вы писали:

IT>>>Бред какой-то А чем тебя SQL не устраивает? Тем что его написал не ты?
_>>Эм, предлагаю тебе перечитать всю данную тему с самого начала... ))) Данный вопрос подробно изложен в ней, причём многими людьми.
IT>Периодически я тратил своё драгоценное время на эти, прости господи, изложения. Ничего интересного ни разу не обнаружил. Идеализм, шапкозакидательство и, чаще всего, непонимание того, что из себя представляет разработка приложений, использующих базы данные.

Ну так если ты уже читал моё мнение по данной теме, то к чему тогда был этот твой вопрос?

Здравствуйте, alex_public, Вы писали:

_>Ну так если ты уже читал моё мнение по данной теме, то к чему тогда был этот твой вопрос?

Может читал, может нет. Я не помню. Да и вопрос был чисто риторический.

Я вообще, если честно, удивлён. Ладно бы если бы это были "юноша бледный со взором горящим", но вы вроде мужики уже взрослые, а как дети
SQL широко известен и массово используется уже лет 30 минимум. 20 лет без него не обходится ни одно бизнес приложение в мире. Вы думаете если бы было всё так плохо и он не устраивал разработчиков, то он до сих пор был бы жив? Да за в половину меньший срок, за каких-то 10 лет, веб поменял своё лицо уже двести раз. Куча технологий появилась и умерла. А уж популярность этого дела никак не меньше, чем у SQL. Но вот почему-то SQL устраивает всех, кроме вас, а веб не пнул только ленивый.

Успокойтесь уже. Всё с SQL хорошо. Никакие мапредьюсы с ноусиквелами ему не грозят. Либо забьются обратно в свои изначальные ниши, точнее в щели, либо сдохнут.