Есть некоторые архитектурные препятствия для создания более умных языков запросов в диспетчере баз данных. Основной из них - оптимизатор запросов. Одним из конструктивных ограничений для SQL является то, что он может использовать только конструкции, доступные для оптимизатора запросов. Это означает, что язык и его возможности достаточно тесно связаны с возможностями механизма выполнения запросов и оптимизатора плана запросов.
Другим основным ограничением конструкции является механическая природа системы баз данных - программирование базы данных почти уникально тем, что оно имеет механический компонент. Производительность запроса ограничена механическими ограничениями обращений к головке диска и задержкой вращения (время ожидания до того, как данные вы хотите получить под головами).
Это эффективно исключает множество умных абстракций, которые могут сделать SQL более мощным или более легким в работе. Многие системы управления базами данных дополняют SQL процедурами, которые могут использоваться для сценариев. Однако они взаимодействуют с СУБД , выполняя серию SQL-запросов, которые обрабатываются оптимизатором индивидуально. Некоторые языки этого типа, которые поставляются с различными СУБД платформ:
Oracle'sPL/SQL и embedded Java. PL/SQL - это на самом деле на основе Ada - довольно «старая школа» по современным меркам и имеет устаревшую базу кода, с которой она должна оставаться обратно совместимой. Это не обязательно самая приятная среда программирования, но у нее есть конструкции для объектов, таких как параллельность и достаточно гибкая система типов. Одной из основных причин критики Java-хранимых процедур на Oracle является то, что вы платите за Лицензирование на основе мощности Oracle на на процессоре, на котором работает JVM .
SQL Server CLR Integration. В некоторой степени похожая на Oracle Java Хранимые процедуры, это позволяет использовать модули CLR , скомпилированные из C# (или любого другого).net ), который должен быть загружен в экземпляр SQL Server и выполнен таким же образом, как и хранимые процедуры таким образом: . SQL Server также имеет API-интерфейс PostgreSQL для создания настраиваемых функций агрегации через CLR интеграция и другие крючки для смешанных баз кода SQL/CLR.
PostgreSQL на самом деле система, в которой первоначально был разработан фоновым язык интеграции. Система экспортирует native C API с объектами для пользовательских агрегатных функций, хранения двигателей, процедурных расширений и других функций . The language interfaces основаны на этом API и включают в себя: PL/pgSQL (сделанный на заказ язык похож на PL/SQL), Python, Perl и Tcl.
Это сделало его в русло через Illustra, а на коммерческую версию Postgres, который затем выкуплена Informix (который был впоследствии выкуплена IBM). Ключи были включены в Informix On-Line, который является , еще проданным IBM.
Одним из ключевых ограничений этих языков является их ограниченное взаимодействие с запроса оптимизатора (хотя C API для PostgreSQL действительно имеет поддержку для этого). Участие в плане запросов в качестве первоклассного гражданина требует, чтобы оптимизатор запросов мог выработать разумный взгляд на ресурсы, которые будут предпринимать ваши действия. На практике такой тип взаимодействия с оптимизатором запросов в основном полезен для реализации механизмов хранения.
Этот уровень копания в двигателе хранения (a) несколько эзотеричен, если функциональность доступна вообще (так что большинство людей не будет иметь навыков для этого) и (б), вероятно, гораздо больше проблем, чем просто писать запрос в SQL. Ограничения оптимизатора запросов означают, что вы, вероятно, никогда не получите уровень абстракции из SQL, из которого вы можете получить (скажем) Python или даже C# или Java.
Путь наименьшего сопротивления для эффективных запросов, вероятно, будет , записывающий запрос в SQL с некоторым процедурным клеем на одном из других языков. В некоторых случаях вычисление действительно поддается процедурному подходу.
Это может стать хлопот и привести к большим телам кода SQL-кода. Единственными реальными вариантами для этого являются системы кодирования SQL или кода с ручным кодированием. Тривиальным примером генерации кода является функциональность CRUD, предоставляемая фреймворками, где этот SQL генерируется из метаданных. Более сложный пример можно увидеть в инструментах ETL, таких как Oracle Warehouse Builder или Wherescape Red, которые работают, создавая отличные стяжки кода хранимой процедуры из модели.
По этой причине я нахожу себе системы генерации кода того или иного типа на регулярной основе. Любая система шаблонов сделает для этого - у меня был довольно хороший пробег от CherryTemplate, но таких предметов много. Code Generation in Action - довольно хорошая книга на эту тему - автор использует рубиновую систему, чье имя ускользает от меня.
Редактировать: Если вы посмотрите на «Показать оценочный план выполнения» для блока процедурного кода, вы заметите, что каждый оператор имеет свой собственный план запросов. Алгоритм оптимизации запросов может работать только на одном SQL-запросе, поэтому процедура будет иметь лес планов запросов. Поскольку процедурный код может иметь «side-effects», вы не можете использовать type of algorithms, используемый в оптимизации запросов, чтобы обосновать код. Это означает, что оптимизатор запросов не может глобально оптимизировать блок процедурного кода. Он может оптимизировать только отдельные операторы SQL.
@Kev Пожалуйста, откройте этот вопрос. – PHPst 2013-10-02 04:10:06