Quais são as boas alternativas para SQL (a linguagem)? [fechadas]

Ocasionalmente, ouço coisas sobre como SQL é uma merda e não é uma boa linguagem, mas nunca ouço falar muito sobre alternativas a ela. Então, há outras linguagens boas que têm o mesmo propósito (acesso ao banco de dados) e o que as torna melhores que o SQL? Existem bons bancos de dados que usam essa linguagem alternativa?

EDIT: Estou familiarizado com SQL e uso-o o tempo todo. Não tenho nenhum problema com isso, só estou interessado em quaisquer alternativas que possam existir e por que as pessoas gostam mais delas.

Também não estou procurando tipos alternativos de bancos de dados (o movimento NoSQL), apenas maneiras diferentes de acessar bancos de dados.

Certamente concordo que é difícil trabalhar com a sintaxe SQL, tanto do ponto de vista de gerá-la automaticamente, quanto do ponto de vista de analisá-la, e não é o estilo de linguagem que escreveríamos hoje se estivéssemos projetando SQL para as demandas que colocamos sobre isso hoje. Não acho que encontraríamos tantas palavras-chave variadas se projetássemos a linguagem hoje, suspeito que a sintaxe de junção seria diferente, funções como GROUP_CONCATteriam uma sintaxe mais regular em vez de colocar mais palavras-chave no meio dos parênteses para controlar seu comportamento ... crie sua própria lista de inconsistências e redundâncias em SQL que você gostaria / espera ver eliminada se redesenharmos a linguagem hoje.

Não existem alternativas ao SQL para se comunicar com bancos de dados relacionais (ou seja, SQL como um protocolo), mas existem muitas alternativas para escrever SQL em seus aplicativos. Essas alternativas foram implementadas na forma de front-ends para trabalhar com bancos de dados relacionais. Alguns exemplos de front-end incluem:

• SchemeQL e CLSQL , que são provavelmente os mais flexíveis, devido à sua herança Lisp, mas também se parecem muito mais com SQL do que outros front-ends.
• LINQ (em .Net)
• ScalaQL e ScalaQuery (em Scala)
• SqlStatement , ActiveRecord e muitos outros em Ruby,
• HaskellDB
• ... a lista continua para muitos outros idiomas.

Acho que o tema subjacente hoje é que, em vez de substituir o SQL por uma nova linguagem de consulta, estamos criando front-ends específicos de linguagem para ocultar o SQL em nossas linguagens de programação normais do dia-a-dia e tratando o SQL como o protocolo para falar com relacional bancos de dados.

Dê uma olhada nesta lista.

O Hibernate Query Language é provavelmente o mais comum. A vantagem do Hibernate é que os objetos mapeiam muito facilmente (quase automaticamente) para o banco de dados relacional, e o desenvolvedor não precisa gastar muito tempo fazendo o design do banco de dados. Verifique o site do Hibernate para mais informações. Tenho certeza de que outros irão intervir com outras linguagens de consulta interessantes ...

Claro, há muitas coisas NoSQL por aí, mas você menciona especificamente que não está interessado nelas.

"Eu ocasionalmente ouço coisas sobre como o SQL é uma merda e não é uma boa linguagem"

O SQL tem mais de trinta anos. As percepções sobre "quais recursos tornam algo uma linguagem 'boa' e quais a tornam uma linguagem 'ruim'" evoluíram mais rapidamente do que o próprio SQL.

Além disso, SQL não é uma linguagem que está em conformidade com os padrões atuais de "o que é necessário para ser relacional", portanto, SQL simplesmente não é uma linguagem relacional para inicializar.

"mas nunca ouço falar muito sobre alternativas a isso."

Convido você a refletir sobre a possibilidade de estar tentando ouvir apenas nos lugares errados (ou seja, exclusivamente na indústria comercial de DBMS).

"Então, há outras linguagens boas que têm o mesmo propósito (acesso ao banco de dados) e o que as torna melhores do que o SQL?"

Date & Darwen descrevem as características às quais uma linguagem moderna de manipulação de dados deve se conformar em seu "Terceiro Manifesto", a versão mais recente do qual consta em seu livro "Bancos de dados, Tipos e Modelo Relacional".

"Existem bons bancos de dados que usam essa linguagem alternativa?"

Se por "bom" você quer dizer algo como "força industrial", então não. A coisa mais próxima disponível provavelmente seria Dataphor.

O projeto Rel oferece uma implementação para a linguagem Tutorial D definida em "Bancos de dados, Tipos e Modelo Relacional", mas o objetivo principal atual do Rel é ser educacional por natureza.

Meu projeto SIRA_PRISE oferece uma implementação para gerenciamento de dados "verdadeiramente relacional", mas eu hesito em rotulá-lo também como "uma implementação de uma linguagem".

E, claro, você também pode examinar algumas coisas não relacionais, como alguns propuseram, mas eu pessoalmente rejeito o gerenciamento de dados não relacionais como várias décadas de regressão tecnológica. Isso não vale a pena considerar.

Ah, e por falar nisso, um sistema de software que é usado para gerenciar bancos de dados não é "um banco de dados", mas "um sistema de gerenciamento de banco de dados", "DBMS" para breve. Assim como uma fotografia não é a mesma coisa que uma câmera, e se você estiver discutindo sobre câmeras e quiser evitar confusão, use a palavra adequada "câmeras" em vez de "fotografia".

Talvez você esteja pensando na crítica que C. Date e seus amigos fizeram contra os bancos de dados relacionais existentes e SQL; eles dizem que os sistemas e a linguagem não são 100% relacionais e deveriam ser. Eu realmente não vejo nenhum problema real aqui; Pelo que eu posso ver, você pode ter um sistema 100% relacional, se quiser, apenas disciplinando a maneira como você usa o SQL.

O que eu pessoalmente continuo encontrando é a falta de poder expressivo que o SQL herda de sua base teórica, a álgebra relacional. Um problema é a falta de suporte para o uso de ordenação de domínio, que você encontra quando trabalha com dados marcados por datas, carimbos de data / hora, etc. Certa vez, tentei fazer um aplicativo de relatório inteiramente em SQL simples em um banco de dados cheio de carimbos de data / hora e simplesmente não era viável. Outra é a falta de suporte para a travessia de caminho: a maioria dos meus dados parecem gráficos direcionados nos quais preciso percorrer os caminhos, e o SQL não pode fazer isso. (Falta "fechamento transitivo". SQL-1999 pode fazer isso com "subconsultas recursivas", mas ainda não as vi em uso real. Existem também vários hacks para fazer o SQL lidar, mas eles são feios.) Esses problemas são também discutido por alguns dos escritos de Date, a propósito.

Recentemente, fui apontado para .QL, que parece resolver muito bem o problema de fechamento transitivo, mas não sei se pode resolver o problema com domínios ordenados.

Resposta direta: não acho que haja nenhum candidato sério por aí. DBase e seus imitadores (Foxpro, Codebase etc) foram um competidor por um tempo, mas eu acho que eles basicamente perderam a guerra de linguagem de consulta de banco de dados. Existem muitos outros produtos de banco de dados que têm sua própria linguagem de consulta, como Progress e Paradox e vários outros que usei cujos nomes não lembro e certamente muitos mais dos quais nunca ouvi falar. Mas não acho que nenhum outro concorrente chegou perto de obter uma fatia não trivial do mercado.

Como prova simples de que há uma diferença entre um formato de banco de dados e uma linguagem de consulta, a última versão do DBase que usei - muitos anos atrás - ofereceu tanto a linguagem de consulta "tradicional" DBase quanto SQL, que poderiam ser usadas para acessar os mesmos dados.

Divagação lateral: Eu não diria que SQL é uma merda, mas tem muitas falhas. Com o benefício dos anos de experiência e visão retrospectiva que temos agora, tenho certeza que seria possível projetar uma linguagem de consulta melhor. Mas criar uma linguagem de consulta melhor e convencer as pessoas a usá-la são duas coisas muito diferentes. Seria melhor convencer as pessoas de que valeu a pena aprender. As pessoas investiram muitos anos de suas vidas aprendendo a usar o SQL de maneira eficaz. Mesmo que seu novo idioma seja mais fácil de usar, certamente haverá uma curva de aprendizado. E como você migraria seus sistemas existentes de SQL para a nova linguagem? Etc. Isso pode ser feito, é claro, assim como C ++, C # e Java derrubaram amplamente o COBOL e o FORTRAN. Mas é necessária uma combinação de superioridade técnica e bom marketing para conseguir isso.

Ainda assim, recebo uma risada das pessoas que correm para defender o SQL sempre que alguém o critica, que insistem que qualquer problema que você tenha com o SQL deve ser sua própria inaptidão em usá-lo e não qualquer falha do SQL, que você simplesmente não deve ter atingiu o plano superior de coisas necessárias para compreender sua perfeição, etc. Acalme-se, respire fundo: estamos insultando uma linguagem de computador, não sua mãe.

Dê uma olhada em LINQ to SQL ...

Tentei alguns meses atrás e nunca mais olhei para trás ...

Na década de 1980, ObjectStore fornecia acesso transparente a objetos. Era como um RDBMS mais um ORM, exceto sem todas aquelas camadas de abstração extras: ele armazenava objetos diretamente no banco de dados.

Portanto, esta alternativa era realmente "nenhuma linguagem", ou talvez "a linguagem que você já está usando". Você escreveria código C ++ e criaria ou atravessaria objetos como se fossem objetos nativos, e o banco de dados cuidaria de tudo conforme necessário. Mais ou menos como o ActiveRecord, mas na verdade funcionou tão bem quanto afirmam as blitzes de marketing do ActiveRecord. :-)

(Claro, ele não tinha o músculo de marketing da Oracle e não tinha o custo zero do MySQL, então todo mundo o ignorou. E agora tentamos replicar isso com RDBMSs e ORMs, e algumas pessoas tentam argumentar que as tabelas realmente faz sentido para armazenar objetos, e escrever um arquivo XML gigante para dizer ao seu computador como mapear objetos para tabelas é de alguma forma uma solução razoável.)

O movimento geral hoje em dia é o NoSQL; geralmente essas tecnologias são:

• Distribuídos "hashtables" que armazenam dados como pares chave / valor
• Bancos de dados orientados a documentos

Pessoalmente, acho que não há nada de errado com o SQL, desde que ele atenda às suas necessidades. SQL é expressivo e ótimo para trabalhar com dados estruturados.

Acho que você pode estar interessado em examinar o Dataphor , que é um ambiente de desenvolvimento relacional de código aberto com seu próprio servidor de banco de dados (que fala D) e a capacidade de derivar interfaces de usuário de sua linguagem de consulta.

Além disso, parece que Ingres ainda oferece suporte a QUEL e é de código aberto.

O SQL funciona bem para o domínio para o qual foi projetado - tabelas de dados inter-relacionadas. Isso geralmente é encontrado no processamento de dados de negócios tradicional. SQL não funciona muito bem ao tentar persistir uma rede complexa de objetos.

Se suas necessidades forem armazenar e processar dados relativamente tradicionais, use algum DBMS baseado em SQL.

Em resposta à sua edição:

Se você está procurando alternativas ao SQL DML para recuperar dados de armazenamentos de dados relacionais, nunca ouvi falar de nenhuma alternativa séria ao SQL.

Os golpes que o SQL recebe não são, eu acho, muito contra a linguagem, em oposição aos princípios de armazenamento de dados subjacentes nos quais a linguagem é baseada. Muitas vezes as pessoas confundem a linguagem SQL com o modelo de dados relacional no qual os RDBMSs são construídos.

Bancos de dados relacionais não são o único tipo de banco de dados que existe. Devo dizer uma palavra sobre Bancos de Dados de Objetos, pois não tenho visto nas respostas de outras pessoas. Eu tive alguma experiência com o framework Zope python que usa ZODB para persistência de objetos em vez de RDBMS (bem, é teoricamente possível substituir o ZODB por outro banco de dados dentro do zope, mas da última vez que verifiquei não tive sucesso em fazê-lo funcionar, então pode seja positivo sobre isso).

A mentalidade do ZODB é realmente diferente, mais parecida com a programação de objetos que seria persistente.

ORM pode ser visto como um tipo de linguagem

De certa forma, acredito que o modelo de banco de dados de objeto é o que ORM trata: acessar dados persistentes por meio de seu modelo de objeto usual. É um tipo de linguagem e está ganhando alguma participação no mercado, mas por enquanto não a vemos como uma linguagem, mas como uma camada de abstração. No entanto, acredito que seria muito mais eficiente usar um ORM sobre um banco de dados-objeto do que sobre SQL (em outras palavras, o desempenho de ORMs que usei usando algum banco de dados SQL como camadas de base foi uma droga).

Existem muitas implementações de SQL (SQL Server, mysql, Oracle, etc.), mas não há outra linguagem que sirva ao mesmo propósito no sentido de ser uma linguagem de propósito geral projetada para armazenamento e recuperação de dados relacionais .

tem bancos de dados de objetos , como db4o , e existem também os chamados bancos de dados noSQL que se referem a praticamente qualquer mecanismo de armazenamento de dados que não depende de SQL, mas mais comumente produtos de código aberto como Cassandra baseados vagamente no conceito Bigtable do Google .

Existem também vários produtos de banco de dados de propósito especial, como o CDF, mas você provavelmente não precisa se preocupar com eles - se precisar, você saberá.

Nenhum deles é equivalente a SQL.

Isso não significa que eles sejam "melhores" ou "piores" - eles simplesmente não são iguais. Dennis Forbes escreveu um ótimo post recentemente detalhando uma série de declarações estranhas que surgiram contra o SQL. Ele afirma (e eu concordo) que essas reclamações se originam em grande parte de pessoas e lojas que escolheram a ferramenta errada para o trabalho em primeiro lugar ou não estão usando seu SGBD SQL corretamente (nem fico mais surpreso quando eu veja outro banco de dados SQL onde cada coluna é um varchar(50)e não há um único índice ou chave, em qualquer lugar).

Se você estiver implementando mais um site de rede social e não estiver muito preocupado com os princípios do ACID , comece a pesquisar produtos como o db4o. Se você está desenvolvendo um sistema de negócios de missão crítica, no entanto, eu altamente altamente recomendo que você pense duas vezes antes de entrar para o "SQL suga" coro. Faça a pesquisa primeiro, descubra quais recursos os vários produtos podem e não podem oferecer suporte.

Editar - Eu estava ocupado escrevendo minha resposta e não obtive a atualização da pergunta por alguns minutos. Dito isso, o SQL é essencialmente inseparável do próprio DBMS. Se você executar um produto de banco de dados SQL, poderá acessá-lo com SQL, ponto final.

Talvez você esteja procurando abstrações sobre a sintaxe; Linq to SQL, Entity Framework, Hibernate / NHibernate, SubSonic e uma série de outras ferramentas ORM fornecem sua própria sintaxe semelhante a SQL que não é exatamente SQL. Tudo isso "compila" para SQL. Se você executar o SQL Server, também poderá escrever Funções / Procedimentos / Gatilhos CLR, que permitem escrever código em qualquer linguagem .NET que será executada dentro do banco de dados; entretanto, isso não é realmente um substituto para o SQL, mais uma extensão para ele.

Não conheço nenhuma "linguagem" completa que possa ser aplicada em camadas sobre um banco de dados SQL; antes de mudar para um produto de banco de dados diferente, você eventualmente verá SQL em funcionamento.

SQL é de fato.

Frameworks que tentam proteger os desenvolvedores disso eventualmente criaram sua própria linguagem específica (Hibernate HQL vem à mente).

SQL resolve um problema muito bem. Não é mais difícil de aprender do que uma linguagem de programação de alto nível. Se você já conhece uma linguagem funcional, é muito fácil entender o SQL.

Considerando que os principais fornecedores de banco de dados que fornecem bancos de dados de última geração (Oracle e SQL Server) suportam SQL e investiram anos em motores de otimização, etc. e todos os principais softwares de modelagem de dados e negócios de software de gerenciamento de mudanças em SQL, eu diria que é o aposta mais segura.

Além disso, um banco de dados envolve mais do que apenas consultas. Existe escalabilidade, backup e recuperação, mineração de dados. Os grandes fornecedores oferecem suporte a muitas coisas que nem mesmo os novos mecanismos de "cache" consideram.

Problemas com SQL me motivaram a preparar um rascunho de linguagem de consulta chamada SMEQL no wiki Portland Pattern Repository . Comentários Bem-vindos. Ele empresta ideias da programação funcional e da linguagem experimental Business System 12 da IBM. (Eu originalmente o chamei de TQL, mas descobri mais tarde que esse nome já existia.)

Dentro do mundo .NET, embora ainda tenha uma sensação SQL, o LINQ-to-SQL permitirá que você tenha uma boa combinação de processamento de dados SQL e .NET na memória. Também simplifica muito o encanamento de dados de nível inferior que ninguém realmente deseja fazer.

Se você deseja ver um tipo de banco de dados com uma mentalidade completamente diferente, dê uma olhada no CouchDB . "Melhor" é obviamente um requisito relativo e esse tipo de banco de dados sem relação é "Melhor", mas apenas em determinados cenários.

SQL a linguagem é muito poderosa e os sistemas de gerenciamento de banco de dados relacional foram e ainda são um grande sucesso. Mas existe uma classe de aplicativo que requer escalabilidade e disponibilidade muito altas, mas não necessariamente um alto grau de consistência de dados (consistência eventual é o que importa). Uma variedade de sistemas obtém melhor desempenho e escala do que um RDBMS, relaxando a necessidade de transações totalmente compatíveis com ACID. Eles foram chamados de "NoSQL", mas, como outros apontam, esse é um nome impróprio: talvez devessem ser chamados de bancos de dados NoACID.

Michael Stonebraker aborda isso em A discussão "NoSQL" não tem nada a ver com SQL .