Por que bancos de dados relacionais só aceitam consultas SQL?

14

Até onde eu sei, a maioria dos bancos de dados relacionais não oferece nenhuma API de nível de driver para consultas, exceto uma função query que usa uma string SQL como argumento.

Estou pensando em como seria mais fácil se alguém pudesse fazer isso:

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

Para tabelas unidas, seria um pouco mais complexo, mas ainda assim possível. Por exemplo:

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

Código mais limpo, sem overhead de análise de string, sem problemas de injeção, reutilização mais fácil dos elementos de consulta ... Posso ver muitas vantagens.

Existe uma razão específica pela qual foi escolhido apenas fornecer acesso a consultas por meio do SQL?

    
por lortabac 21.03.2013 / 15:56
fonte

4 respostas

33

Bancos de dados estão fora de processo - eles são executados em um servidor diferente normalmente. Assim, mesmo se você tivesse uma API, seria necessário enviar algo através da rede que representa sua consulta e todas as suas projeções, filtros, grupos, subconsultas, expressões, junções, funções agregadas, etc. Esse algo poderia ser XML ou JSON ou algum formato proprietário, mas também pode ser SQL, porque isso é experimentado, testado e suportado.

Hoje em dia é menos comum criar comandos SQL - muitas pessoas usam algum tipo de ORM. Mesmo que estes acabem se traduzindo em instruções SQL, eles podem fornecer a API que você procura.

    
por 21.03.2013 / 16:09
fonte
33

Como o SQL fornece uma API comum. Você pode escrever um driver compatível com ANSI 92 SQL que emite SQL e expõe a API desejada. Como um bônus especial, ele funcionará com praticamente qualquer banco de dados SQL sem reescrever.

Se isso fosse feito do seu jeito, cada banco de dados SQL teria uma API diferente. A menos, claro, todos nós padronizamos em sua API. Mas então, nós teríamos SQL novamente, mais ou menos, não é? Exceto que sua API parece ser específica para linguagem de programação, enquanto SQL não é.

    
por 21.03.2013 / 16:09
fonte
7

Há mais o que fazer no banco de dados para fins administrativos, portanto, é importante poder criar scripts e enviar textos para adicionar usuários, executar backups, carregar dados, alterar o esquema etc. A maioria dos DBAs não vai querer fazer isso dentro de alguma outra linguagem de programação.

Se o DBA quiser se agarrar ao SQL, você precisa ter outro idioma, o banco de dados teria o ônus de processar ambos.

Existem muitos recursos novos em bancos de dados, então não acho que eles estejam ficando estagnados. Eles simplesmente não estão fazendo o que você propõe por algum motivo.

O SQL Server tem a capacidade de executar o código .NET desde o interior até o SQL CLR. Isso é útil para algumas dessas tarefas que não se encaixam em um modelo relacional, mas desejam manter o desempenho. Eu percebo que isso não é o que você está procurando. É um exemplo das muitas coisas que os bancos de dados estão fazendo.

Não vai desaparecer tão cedo. Um dos bancos de dados mais recentes a chegar ao mercado é o NuoDB . Eles mantiveram o SQL, fornecem o ACID ao mesmo tempo em que adicionam a capacidade de distribuir servidores e executá-lo em uma nuvem. Você pode querer saber por que eles tiveram todo esse trabalho para promover a continuação do SQL (não é a única razão deles, mas é um grande ponto de venda).

    
por 21.03.2013 / 21:49
fonte
3

O SQL DBMS fornece acesso substancialmente otimizado à loja por meio do idioma nativo, e muitos, como você observou, não fornecem nenhuma outra API.

A observação de que o banco de dados está fora de processo não se aplica em vários casos e não é diretamente relevante.

Até mesmo bancos de dados que exigem o uso do SQL DML geralmente fornecem uma biblioteca de cursores para fornecer acesso ao iterador a um conjunto de resultados, e os conhecidos Microsoft Access e Btrieve SQL DBMS fornecem uma interface de registro direto para as tabelas individuais em um banco de dados como um mecanismo para acesso de alto desempenho em circunstâncias específicas.

Como observado, consultas complexas usando essa sintaxe reproduzem o comportamento de bancos de dados de rede do final dos anos 70.

Os mecanismos de acesso alternativos são menos atraentes para os usuários mainstream devido ao desconhecimento, mas o crescimento da popularidade dos bancos de dados NoSQL pode aumentar o interesse em outras APIs para alcançar ganhos específicos de desempenho. Parece pouco mais para recomendar tal abordagem.

    
por 21.03.2013 / 23:47
fonte

Tags