Языки запросов
Вот есть SQL со всеми его диалектами и прочие, довольно экзотические, языки запросов. Не всем они нравятся - но что придёт им на смену?
С одной стороны, в целом вещь хорошая. SQL-запрос абстрактен от реализации, он только описывает получаемые данные и их связь с оставшимися - и в этом смысле SQL воплощает те надежды, которые возлагались на язык Пролог. В других языках такого может и не быть - и приходится интегрировать своё решение на другом языке c SQL.
С другой стороны - как происходит эта интеграция? Вот есть веб-приложение, приходит от клиентской части HTTP-запрос, "средний слой" преобразует его в (SQL-)запрос и переправляет серверу БД. Часто это преобразование не сводится к простой подстановке параметров, и запрос получается сложным (в силу недостатков языка запросов) и плохо читаемым человеком. Какие возможны выходы:
1. Формирование запроса как объекта - и дальнейшее преобразование в запрос на SQL. В предельном случае преобразование будет абстрактно от текущего проекта, и выполнено в виде отдельной библиотеки. Язык запросов в таком случае подменяется интерфейсами для формирования запроса-объекта - мы получаем вместо двух разных языков один с новым подмножеством, а старый язык тогда остаётся языком "сериализации" объектов-запросов. С одной стороны, шагом к этому была Java Persistence Architecture с её CriteriaBuilder - но возможности построенных абстрактных от СУБД запросов намного скромнее, чем у запросов на конкретном диалекте SQL; с другой, можно вспомнить MongoDB, у которой запросы - просто JSON (то есть уже готовый механизм сериализации используется).
2. Формирование запроса с помощью движков шаблонов - кто-нибудь пробовал??
3. Более тесная интеграция языка среднего слоя внутрь сервера базы данных, переход на какой-нибудь RPC с привычными прозрачными интерфейсами. Тут плохо то, что реализации RPC тоже уже старые и громоздкие (SOAP ещё вспомните), а сами языки "среднего слоя" более императивны, чем декларативны (но тут есть подвижки, типа unapply в Scala), и эта декларативность может помешать использовать внутреннюю оптимизацию запросов. Хотя запросы бывают разные, вручную их тоже оптимизировать бывает надо.
Upd. 4. Вариант, который я не сразу вспомнил , а ведь сталкивался - максимально перенести логику в хранимые процедуры, усложнить статически SQL-код. Можно ведь уже сейчас много что делать, вплоть до сериализации прямо внутри SQL, да? Проблема использования версионности, синхронизации кода в VCS и базе - чисто техническая. То, что получится, будет меньше испытывать проблем от применения двух разных языков, и больше - от недостатков самого SQL.