Ответ 1
Есть некоторые архитектурные препятствия для создания более умных языков запросов в менеджере баз данных. Основной из них - оптимизатор запросов. Одним из конструктивных ограничений для SQL является то, что он может использовать только конструкции, доступные для оптимизатора запросов. Это означает, что язык и его возможности достаточно тесно связаны с возможностями механизма выполнения запросов и оптимизатора плана запросов.
Другим основным конструктивным ограничением является механическая природа системы баз данных - программирование базы данных почти уникально тем, что оно имеет механический компонент. Производительность запроса ограничена механическими ограничениями обращений к головке диска и задержкой вращения (время ожидания до того, как данные вы хотите получить под головами).
Это эффективно исключает многие умные абстракции, которые могут сделать SQL более мощным или более легким в работе. Многие системы управления базами данных дополняют SQL процедурами, которые могут использоваться для сценариев. Однако они взаимодействуют с СУБД выполняя серию SQL-запросов, которые обрабатываются оптимизатором индивидуально. Некоторые языки этого типа, поставляемые с различными платформами СУБД,:
-
Oracle PL/SQL и встроенная Java. PL/SQL - это фактически основанный на Аде - это вполне "старая школа" по современным стандартам и имеет устаревшую базу кода, с которой она должны оставаться обратно совместимыми. Это не обязательно приятная среда программирования, но у него есть конструкции для таких как parallelism и достаточно гибкая система типов. Один из основных критика хранимых процедур Java на Oracle - это то, что вы платите Лицензирование на базе мощностей Oracle CPU, на котором вы работаете, JVM на.
-
SQL Server Интеграция CLR. Совсем похоже на Oracle Java Хранимые процедуры, это позволяет CLR модули, скомпилированные из С# (или любой .net язык) для загрузки в SQL Server экземпляр и выполняются почти так же как хранимые процедуры. SQL Server также имеет API-интерфейс PostgreSQL для создания пользовательские агрегатные функции через CLR интеграции и других перехваты для смешанных баз данных SQL/CLR.
-
PostgreSQL на самом деле система, в которой используется исходный язык интеграция была первоначально разработаны. Система экспортирует собственный C API с возможностями для пользовательские агрегированные функции, хранение двигатели, процедурные расширения и другие функциональность. Языковые интерфейсы основаны на этом API и включают: PL/pgSQL (похожий на языке язык к PL/SQL), Python, Perl и Tcl.
Это сделало это main через Illustra, a коммерциализированная версия Postgres, который затем был выкуплен Informix (впоследствии выкупленных IBM). Ключ функции были включены в Informix On-Line, который все еще продается IBM.
Одним из ключевых ограничений этих языков является их ограниченное взаимодействие с запросом оптимизатора (хотя API C для PostgreSQL имеет поддержку для этого). Участие в плане запросов в качестве первоклассного гражданина требуется, чтобы оптимизатор запросов мог выработать разумный взгляд на ресурсы, которые будут предпринимать ваши действия. На практике такой тип взаимодействия с оптимизатором запросов в основном полезен для реализации механизмов хранения.
Этот уровень копания в движке хранения (a) несколько эзотеричен, если функциональность доступна вообще (так что большинство людей не будет иметь навыков для этого) и (б), вероятно, значительно больше проблем, чем просто писать запрос в SQL. Ограничения оптимизатора запросов означают, что вы, вероятно, никогда не получите уровень абстракции из SQL, из которого вы можете получить (скажем) Python или даже С# или Java.
Путь наименьшего сопротивления для эффективных запросов, вероятно, будет написав запрос в SQL с некоторым процедурным клеем на одном из других языков. В некоторых случаях вычисление действительно поддается процедурному подходу.
Это может стать проблемой и привести к большим объемам кода SQL-кода. Единственными реальными вариантами для этого являются системы кодирования SQL или кода с ручным кодированием. Тривиальным примером генерации кода является функциональность CRUD, предоставляемая фреймворками, где этот SQL генерируется из метаданных. Более сложный пример можно увидеть в инструментах ETL, таких как Oracle Warehouse Builder или Wherescape Red, которые работают, создавая отличные стяжки кода хранимой процедуры из модели.
Я обнаружил, что именно по этой причине я создаю системы генерации кода того или иного типа на полу-регулярной основе. Любая система шаблонов сделает это - у меня был довольно хороший пробег от CherryTemplate, но таких предметов много. Code Generation in Action - довольно хорошая книга на эту тему - автор использует рубиновую систему, имя которой ускользает от меня.
Изменить: если вы посмотрите на "Показать оценочный план выполнения" для блока процедурного кода, вы заметите, что каждый оператор имеет свой собственный план запросов. Алгоритм оптимизации запросов может работать только на одном SQL-запросе, поэтому процедура будет иметь лес планов запросов. Поскольку процедурный код может иметь побочные эффекты, вы не можете использовать тип алгоритмы, используемые при оптимизации запросов, чтобы обосновать код. Это означает, что оптимизатор запросов не может глобально оптимизировать блок процедурного кода. Он может оптимизировать только отдельные инструкции SQL.