Quais são boas alternativas ao SQL (o idioma)? [fechado]

Olha para esta lista.

A linguagem de pesquisa Hibernada é provavelmente a 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 tem que gastar muito tempo fazendo o projeto do banco de dados. Confira o site do Hibernatepara mais informações. Tenho a certeza que outros vão entrar em sintonia com outras línguas de consulta interessantes...

Claro que há muitas coisas NoSQL por aí., mas mencionou especificamente que não está interessado nisso.

"Às vezes ouço coisas sobre como o SQL é uma porcaria e não é uma boa língua"

O SQL tem mais de trinta anos. Insights about "which features make something a 'good' language and which ones make it a ' bad ' one " have evolved more rapidly than SQL itself.

Também, SQL não é uma linguagem que se conforma com os padrões atuais de "o que é preciso para ser relacional", então, SQL simplesmente não é uma linguagem relacional para arrancar.

"Mas nunca ouço muito. sobre alternativas."

Convido-vos a reflectir sobre a possibilidade de estarem a tentar ouvir apenas nos locais errados (ou seja, a indústria comercial de SGBD exclusivamente).

" assim, são outras línguas boas que servem o mesmo propósito (acesso à base de dados) e o que as torna melhores do que SQL?"

Date & Darwen descreve as características a que uma linguagem moderna de manipulação de dados deve obedecer em seu "terceiro Manifesto", cuja versão mais recente é colocada down in their book "Databases, Types & the Relational Model".

" existem boas bases de dados que usem esta linguagem alternativa?"

Se por " bom "queres dizer algo como" força industrial", então não. O mais próximo disponível seria Dataphor.

O projecto Rel oferece uma implementação para a linguagem Tutorial D definida em "bases de Dados, tipos e modelo relacional", mas o objectivo principal actual da Rel é Ser Educacional em natureza.

O meu projecto SIRA_PRISE oferece uma implementação para uma gestão de dados" verdadeiramente relacional", mas hesito em rotulá-la como"uma implementação de uma língua". E é claro, Você também pode olhar para algumas coisas não-relacionais, como alguns propuseram, mas eu pessoalmente descarto a gestão de dados não-relacionais como várias décadas de regressão tecnológica. Não vale a pena considerar. E a propósito, um sistema de software que é usado para gerir bases de dados é ... não" um banco de dados", mas" um sistema de gerenciamento de banco de dados"," DBMS " para abreviar. Assim como uma fotografia não é a mesma coisa que uma câmera, e se você está discutindo Câmeras, e você quer evitar confusão, então você deve estar usando a palavra adequada "câmeras" em vez de "fotografia".

Talvez esteja a pensar na crítica C. Date e os seus amigos tenham pronunciado contra as bases de dados relacionais existentes e SQL; dizem que os sistemas e a linguagem não são 100% relacionais, e devem ser. Eu realmente não vejo nenhum problema real aqui; tanto quanto eu posso ver você pode ter um sistema relacional 100%, se você quiser, apenas disciplinando a forma como você usa SQL.

O que eu pessoalmente continuo a encontrar é a falta de poder expressivo SQL herda da sua base teórica., álgebra relacional. Uma questão é a falta de suporte para o uso da encomenda de domínio, que você encontra quando você trabalha com dados marcados por datas, datas, etc. Eu uma vez tentei fazer uma aplicação de relatórios inteiramente em SQL simples em uma base de dados cheia de datas e simplesmente não era viável. Outra é a falta de suporte para o caminho transversal: a maioria dos meus dados parecem gráficos direcionados que eu preciso percorrer caminhos, e SQL não pode fazê-lo. (It lacks "transitive closure". SQL-1999 pode fazê-lo com "subqueries recursivas", mas ainda não as vi em uso real. Há também vários hacks para fazer SQL cope, mas eles são feios.) Estes problemas também são discutidos por alguns dos escritos de Date, A propósito.

Recentemente fui apontado para .QL que parece abordar a questão do fecho transitivo de forma simpática, mas não sei se pode resolver o problema com domínios ordenados.

Olha parao LINQ para o SQL ...

Experimentei-o há uns meses e nunca olhei para trás....

Resposta directa: acho que não há nenhum candidato sério por aí. DBase e seus imitadores (Foxpro, Codebase etc) Foi um candidato por um tempo, mas eu acho que eles basicamente perderam a Guerra da linguagem de consulta de banco de dados. Houve muitos outros produtos de banco de dados que tinham sua própria linguagem de consulta, Como progresso e paradoxo e vários outros que eu usei cujos nomes Eu não me lembro e certamente muitos mais que eu nunca ouvi falar. Mas acho que nenhum outro candidato esteve perto de conseguir um quota de mercado não trivial.

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

Eu não diria que o SQL é uma porcaria, mas tem muitas falhas. Com o benefício dos anos de experiência e retrospectiva que temos agora, tenho certeza que se poderia projetar uma consulta melhor idioma. 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 vale a pena o trabalho de aprender? As pessoas investiram muitos anos de suas vidas aprendendo a usar o SQL de forma eficaz. Mesmo que a sua nova língua seja mais fácil de usar, haveria certamente uma curva de aprendizagem. E como você migraria seus sistemas existentes de SQL para a nova linguagem? Etc. Ele pode ser feito, é claro, assim como C++, C#, e Java derrubou COBOL e FORTRAN. Mas é preciso uma combinação de superioridade técnica e bom marketing para conseguir.

Ainda, eu recebo uma risada de pessoas que correr para a frente para defender o SQL a qualquer momento alguém critica, que insistem que qualquer problema que você tem com o SQL deve ser da sua própria inépcia para usá-lo e não qualquer falha de SQL, que tem apenas não ter alcançado o nível mais elevado de thingking necessário para compreender a sua perfeição, etc. Acalma-te, respira fundo.: Estamos a insultar uma linguagem de computador, não a tua mãe.

O movimento geral nos dias de hoje é NoSQL; geralmente estas tecnologias são:

• distribuidos "hashtables" que armazenam os dados como pares chave/valor
• bases de dados documentais

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

Na década de 1980, a ObjectStore forneceu acesso transparente a objectos. Era como um RDBMS mais um ORM, exceto sem todas aquelas camadas extra de abstração: ele armazenava objetos diretamente na base de dados.

Então esta alternativa era realmente "nenhuma língua", ou talvez "a língua que você já está usando". Você escreveria código C++ e criaria ou atravessaria objetos como se fossem objetos nativos, e a base de dados cuidaria de tudo o que fosse necessário. Mais ou menos. ActiveRecord, mas funcionou bem como a ActiveRecord marketing blitzes. :-)

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

Eu acho que você pode estar interessado em olhar para 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.

Também, parece Ingres {[3] } ainda suporta QUEL, e é open source.

Existem muitas implementações de SQL (Servidor SQL, mysql, Oracle, etc.), mas não há outra língua que sirva o mesmo propósitono sentido de ser uma linguagem de propósito geralconcebida para armazenamento e recuperação de dados relacionais.

Existem bases de dados de objectos tais como db4o , e existem bases de dados similares noSQL que se referem a qualquer mecanismo de armazenamento de dados que não conte com SQL, mas mais comumente produtos de código aberto comoCassandra baseado vagamente no conceito do GoogleBigtable .

Há também uma série de produtos de base de dados para fins especiais, como CDF, mas você provavelmente não precisa se preocupar com isso-se você precisar de um, você saberá.

Nenhum destes é equivalente a SQL.

Isso não significa que sejam "melhores" ou "piores", mas não são iguais. Dennis Forbes escreveu um grande post recentemente, quebrando uma série de estranhas alegações surgindo contra a SQL. Ele afirma (e eu concordo) que essas queixas 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 seus DBMS SQL corretamente (eu não estou mais surpreso quando eu vejo outra base de dados SQL onde cada coluna é um {[[0]} e não há um único índice ou chave, em qualquer lugar).

Se estiver a implementar mais um site de redes sociais e não estão muito preocupados com os princípios de ACID, por todos os meios, comecem a procurar produtos como o db4o. se estão a desenvolver um sistema de negócios crítico para a missão, no entanto, eu altamente recomendo que pensem duas vezes antes de se juntarem ao coro de "SQL suga". Faça a pesquisa primeiro, descubra quais características os vários produtos podem e não podem suportar.

---

Edit - eu estava ocupado escrevendo minha resposta e não recebi a atualização da pergunta de alguns minutos. Dito isto, SQL é essencialmente inseparável do próprio SGBD. Se você executar um produto de banco de dados SQL, então você acessá-lo com SQL, ponto.

Talvez esteja à procura de abstrações sobre a sintaxe; Linq para SQL, Entity Framework, Hibernate/NHibernate, SubSonic, e uma série de outras ferramentas ORM todas fornecem a sua própria sintaxe semelhante a SQL que não é bem SQL. Todos estes "compile down" para SQL. Se você executar o servidor SQL, então você também pode escrever funções CLR / procedimentos/gatilhos, o que lhe permite escrever código em qualquer linguagem. NET que será executado dentro do banco de dados; no entanto, isso não é realmente um substituto para SQL, mais de uma extensão para ele.

Eu não estou ciente de nenhuma "linguagem" completa que você pode camada em cima de uma base de dados SQL; a não ser mudar para um produto de base de dados diferente, você eventualmente vai ver SQL no tubo.

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

Se as suas necessidades são armazenar e processar dados relativamente tradicionais, use alguns SGBD baseados em SQL.

Em resposta à sua edição:

Se está à procura de alternativas ao DML SQL para obter dados a partir de dados relacionais lojas, nunca ouvi falar de nenhuma alternativa séria à SQL.

Os knocks SQL gets não são, eu acho, tanto contra a linguagem, em oposição aos princípios subjacentes de armazenamento de dados em que a linguagem é baseada. As pessoas muitas vezes confundem a linguagem SQL com o modelo de dados relacionais em que os RDBMSes são construídos.

O SQL é de facto.

Frameworks que tentam proteger os desenvolvedores dela acabaram por criar a sua própria linguagem específica (HQL hibernado vem à mente).

O SQL resolve um problema bastante bem. Não é mais difícil aprender do que uma linguagem de programação de alto nível. Se você já conhece uma linguagem funcional, então é uma brisa para captar SQL. Considerando os principais fornecedores de bases de dados que fornecem as bases de dados mais avançadas (Oracle e SQL Server), investiram anos em motores de otimização, etc. e todos os softwares líderes em modelagem de dados e gerenciamento de mudanças em SQL, eu diria que é a aposta mais segura. Além disso, há mais numa base de dados do que apenas perguntas. Há escalabilidade, backup e recuperação, mineração de dados. Os grandes fornecedores suportam um monte de coisas que mesmo os novos motores "cache" não consideram.

As bases de dados relacionais não são o único tipo de bases de dados. Eu deveria dizer uma palavra sobre bases de dados de objetos Como Eu não vi isso em respostas de outros. Eu tive alguma experiência com o framework Zope python que usa ZODB para objetos persistência em vez de RDBMS (bem, teoricamente é possível substituir ZODB por outro banco de dados dentro de zope, mas da última vez que verifiquei eu não consegui fazê-lo funcionar, então não pode ser positivo sobre isso).

O ZODB a mentalidade é realmente diferente, mais como programação de objetos que acontece ser persistente.

ORM pode ser visto como um tipo de linguagem

De certa forma, acredito que o modelo Object-database é o que o ORM é : aceder a dados persistentes através do seu modelo de objecto habitual. É uma espécie de linguagem e está ganhando alguma quota de mercado, mas por enquanto não a vemos como uma linguagem, mas como uma camada de abstração. No entanto, eu acredito que seria muito mais eficiente usar um ORM sobre um objeto-banco de dados do que sobre SQL (em outras palavras, desempenho do ORMs I aconteceu de usar algum banco de dados SQL como camadas base sugadas).

Os problemas com o SQL motivaram-me a criar uma linguagem de consulta chamada SMEQL no repositório de padrões de Portland wiki . Comentários Bem-Vindos. Ele empresta ideias de programação funcional e linguagem experimental do IBM Business System 12. (I originally called it TQL, but found later that name was taken.)

Dentro do mundo. net, enquanto ele ainda tem uma sensação SQL-esque para ele, LINQ-para-SQL permitirá que você tenha uma boa mistura de SQL e em memória. net processamento de seus dados. Ele também simplifica uma grande parte da canalização de dados de nível inferior que ninguém realmente quer fazer.

Se você quiser ver um tipo de base de dados de uma mentalidade completamente diferente, dê uma olhada em CouchDB . "Melhor" é obviamente um requisito relativo e este tipo de base de dados não-relação é "melhor", mas apenas em certos casos cenario.

A Linguagem é muito poderosa, e os sistemas de gestão de bases de dados relacionais têm sido e ainda são um enorme sucesso. Mas há uma classe de aplicação que requer escalabilidade e Disponibilidade muito elevadas, mas não necessariamente um alto grau de consistência de dados (eventual consistência é 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 ácido. Estes foram chamados de "NoSQL" , mas como outros apontam que este é um equívoco: que talvez eles devam ser chamados de bases de dados NoACID.

Michael Stonebraker cobre isto em a discussão "NoSQL" não tem nada a ver com SQL.