¿Por qué las bases de datos relacionales solo aceptan consultas SQL?

Hasta donde sé, la mayoría de las bases de datos relacionales no ofrecen ninguna API de nivel de controlador para consultas, excepto una queryfunción que toma una cadena SQL como argumento.

Estoy pensando en lo fácil que sería si uno pudiera hacer:

var result = mysql.select('article', {id: 3})

Para tablas unidas, sería un poco más complejo, pero aún posible. Por ejemplo:

var tables = mysql.join({tables: ['article', 'category'], on: 'categoryID'});
mysql.select(tables, {'article.id': 3}, ['article.title', 'article.body', 'category.categoryID'])

Código más limpio, sin gastos generales de análisis de cadenas, sin problemas de inyección, reutilización más fácil de elementos de consulta ... Puedo ver muchas ventajas.

¿Hay alguna razón específica por la que se eligió para proporcionar solo acceso a consultas a través de SQL?

Las bases de datos están fuera de proceso, generalmente se ejecutan en un servidor diferente. Entonces, incluso si tuviera una API, necesitaría enviar algo a través del cable que represente su consulta y todas sus proyecciones, filtros, grupos, subconsultas, expresiones, uniones, funciones agregadas, etc. Ese algo podría ser XML o JSON o algunos formato propietario, pero también puede ser SQL porque se prueba, se prueba y se admite.

Es menos común en estos días construir comandos SQL usted mismo: muchas personas usan algún tipo de ORM. Aunque estos finalmente se traducen en declaraciones SQL, pueden proporcionar la API que busca.

Porque SQL proporciona una API común. Puede escribir un controlador compatible con ANSI 92 SQL que emita SQL y exponga la API que desee. Como beneficio adicional, funcionará con casi cualquier base de datos SQL sin tener que volver a escribir.

Si se hiciera a su manera, cada base de datos SQL tendría una API diferente. A menos, por supuesto, que todos estemos estandarizados en su API. Pero entonces, volveríamos a tener SQL, más o menos, ¿no? Excepto que su API parece ser específica del lenguaje de programación, mientras que SQL no lo es.

Hay más cosas que hacer en la base de datos con fines administrativos, por lo que es importante poder escribir y enviar texto para agregar usuarios, ejecutar copias de seguridad, cargar datos, cambiar el esquema, etc. La mayoría de los DBA no querrán hacer esto dentro de algún otro lenguaje de programación.

Si los DBA desean conservar SQL, debe tener otro idioma, la base de datos tendría la carga de procesar ambos.

Hay muchas características nuevas en las bases de datos, por lo que no creo que se estanquen. Simplemente no están haciendo lo que propones por alguna razón.

SQL Server tiene la capacidad de ejecutar código .NET desde adentro a través de SQL CLR. Esto es útil para algunas de esas tareas que no encajan en un modelo relacional, pero que desean mantener el rendimiento. Me doy cuenta de que esto no es lo que estás buscando. Es un ejemplo de las muchas cosas que están haciendo las bases de datos.

No va a desaparecer en el corto plazo. Una de las bases de datos más recientes para llegar al mercado es NuoDB . Mantuvieron SQL, proporcionaron ACID al tiempo que agregaron la capacidad de distribuir servidores y ejecutarlo en una nube. Es posible que desee ver por qué se tomaron tantas molestias para promover la continuación de SQL (no es la única razón, pero es un gran punto de venta).

SQL DBMS proporciona acceso sustancialmente optimizado a la tienda a través del idioma nativo y muchos, como notará, no proporcionan otra API.

La observación de que la base de datos está fuera de proceso no se aplica en varios casos y no es realmente directamente relevante.

Incluso las bases de datos que requieren el uso de SQL DML a menudo proporcionan una biblioteca de cursores para proporcionar acceso iterador a un conjunto de resultados, y los conocidos Microsoft Access y Btrieve SQL DBMS proporcionan una interfaz de registro directo a las tablas individuales en una base de datos como mecanismo para acceso de muy alto rendimiento bajo circunstancias específicas.

Como se señaló, las consultas complejas que utilizan dicha sintaxis reproducirían el comportamiento de las bases de datos de red de finales de los 70.

Los mecanismos de acceso alternativos son menos atractivos para los usuarios principales debido a la falta de familiaridad, pero el crecimiento en popularidad de las bases de datos NoSQL podría aumentar el interés en otras API para lograr ganancias de rendimiento específicas. Parece poco más recomendar un enfoque de este tipo.