Existen algunos obstáculos arquitectónicos para tener lenguajes de consulta más inteligentes en un administrador de base de datos. El principal es el optimizador de consultas. Una de las limitaciones de diseño en SQL es que solo puede usar construcciones accesibles para el optimizador de consultas. Esto significa que el lenguaje y sus capacidades están estrechamente relacionados con las capacidades del motor de ejecución de consultas y el optimizador de planes de consultas.
La otra limitación importante del diseño es la naturaleza mecánica del sistema de la base de datos: la programación de la base de datos es casi única ya que tiene un componente mecánico. El rendimiento de las consultas está limitado por las limitaciones mecánicas de las búsquedas de cabezales de disco y la latencia rotacional (el tiempo de espera antes de que los datos que desea lleguen a los encabezados).
Esto efectivamente excluye muchas abstracciones inteligentes que pueden hacer SQL más poderoso o más fácil de trabajar. Muchos sistemas de administración de bases de datos complementan el SQL con alternativas de procedimientos que pueden usarse para crear scripts. Sin embargo, interactúan con el DBMS por ejecutando una serie de consultas SQL que el optimizador procesa individualmente. Algunos lenguajes de este tipo que se suministran con varias plataformas de DBMS son:
Oracle'sPL/SQL y embedded Java. PL/SQL es realmente basado en Ada - es bastante 'old school' según los estándares modernos y tiene una base de código heredado con la que debe permanecer compatible con versiones anteriores. No es necesariamente el entorno de programación más agradable pero tiene construcciones para instalaciones como el paralelismo y un sistema de tipo razonablemente flexible. Una de las principales críticas de sobre los procedimientos almacenados Java en Oracle es que está pagando por la licencia basada en la capacidad de Oracle en en la CPU en la que está ejecutando el de la JVM.
SQL Server CLR Integration. Algo similar a los procedimientos almacenados Java de Oracle, esto permite CLR módulos compilados desde C# (o cualquiera).net idioma) que se cargará en una instancia de SQL Server y se ejecutará de la misma manera que como procedimientos almacenados. SQL Server también tiene API de estilo PostgreSQL para hacer funciones de agregado personalizadas a través de la integración CLR y otros ganchos para bases de código SQL/CLR mixto.
PostgreSQL es en realidad el sistema donde originalmente fue desarrollado integración de lenguajes de fondo . El sistema exporta un native C API con funciones para funciones de agregado personalizadas, motores de almacenamiento , extensiones de procedimiento y otras funcionalidad. The language interfaces se basan en esta API e incluyen: PL/pgSQL (un lenguaje a medida similares a PL/SQL), Python, Perl y Tcl.
Esto lo hizo en la corriente principal a través Illustra, una versión comercializada de Postgres, que luego fue comprada por Informix (que fue posteriormente comprada por IBM). Las características clave se incorporaron en Informix On-Line, que es aún vendido por IBM.
Una limitación clave de estos idiomas es su interacción limitada con el optimizador de consultas (aunque la API C para PostgreSQL tiene soporte para esto). La participación en un plan de consulta como ciudadano de primera clase requiere que el optimizador de consultas pueda obtener una vista sensata de los recursos que tomará su acción. En la práctica, este tipo de interacción con el optimizador de consultas es principalmente útil para implementar motores de almacenamiento.
Este nivel de búsqueda en el motor de almacenamiento es (a) algo esotérico si la funcionalidad está disponible (por lo que la mayoría de las personas no tendrán la habilidad para hacerlo) y (b) probablemente más problemas que solo escribir la consulta en SQL. Las limitaciones del optimizador de consultas significan que probablemente nunca obtendrá el nivel de abstracción de SQL que podría obtener de (digamos) Python o incluso C# o Java.
La ruta de menor resistencia para consultas eficientes es probable que sea escribiendo la consulta en SQL con algún pegamento de procedimiento en uno de los otros idiomas. En algunos casos, un cálculo realmente se presta a un enfoque de procedimiento.
Esto puede convertirse en una molestia y conducir a grandes cuerpos de código SQL repetitivo. Las únicas opciones reales para esto son sistemas de generación de códigos o SQL codificados a mano. Un ejemplo trivial de generación de código es la funcionalidad CRUD proporcionada por los marcos donde este SQL se genera a partir de metadatos. Se puede ver un ejemplo más complejo en herramientas ETL tales como Oracle Warehouse Builder o Wherescape Red que funcionan generando grandes soleras de código de procedimiento almacenado del modelo.
Me encuentro construyendo sistemas de generación de código de una clase u otra de forma semi-regular precisamente por esta razón. Cualquier sistema de plantillas servirá para esto: he tenido bastante buen rendimiento en el CherryTemplate, pero hay muchos artículos similares. Code Generation in Action es un libro bastante bueno sobre este tema: el autor usa un sistema basado en ruby cuyo nombre se me escapa.
Editar: Si nos fijamos en un 'Mostrar el plan de ejecución estimado' para un bloque de código de procedimiento, observará que cada declaración tiene su propio plan de consulta. El algoritmo de optimización de consultas solo puede funcionar en una única instrucción SQL, por lo que un procedimiento tendrá un bosque de planes de consulta. Como el código de procedimiento puede tener 'side-effects', no puede usar el type of algorithms utilizado en la optimización de consultas para razonar sobre el código. Esto significa que un optimizador de consultas no puede optimizar globalmente un bloque de código de procedimiento. Solo puede optimizar declaraciones SQL individuales.
@Kev Por favor, abra esta pregunta. – PHPst