Por que usar a base de dados SQL? [fechado]

Toda a gente que conheço, incluindo eu, está a usar a ORM.

Estranho. Todos os que conheço, incluindo eu, ainda escrevem a maior parte do SQL à mão. Você normalmente acaba com consultas mais apertadas e de alto desempenho do que com uma solução gerada. E, dependendo da sua indústria e aplicação, esta velocidade importa. Às vezes muito. sim, às vezes vou usar o LINQ para um rápido-n-dirty onde não quero saber como é o SQL resultante, mas até agora nada batidas automáticas sintonizadas manualmente SQL para quando o desempenho contra um grande banco de dados em um ambiente de alta carga realmente importa.

Dado que usaste o MySQL e o SQLite, entendo completamente o teu ponto de vista. A maioria dos DBMS tem recursos que exigiriam alguma da programação do seu lado, enquanto você obtê - lo do banco de dados GRATUITAMENTE:

• Índices - você pode armazenar grandes quantidades de dados e ainda ser capaz de filtrar e pesquisar muito rapidamente, por causa de índices. Claro, você poderia implementar a sua própria indexação, mas por que reinventar a roda

• Integridade dos dados - usar recursos de banco de dados como chaves estrangeiras em cascata pode garantir a integridade de dados em todo o sistema. Você só precisa declarar a relação entre os dados, e o sistema cuida do resto. Claro, mais uma vez, você pode implementar restrições em código, mas é mais trabalho. Considere, por exemplo, a exclusão, onde você teria que escrever código no destruidor do objeto para rastrear todos os objetos dependentes e agir em conformidade

• Capacidade de ter múltiplas aplicações escritas em diferentes linguagens de programação, trabalhando em diferentes sistemas operacionais, alguns até distribuídos através da rede-todos usando os mesmos dados armazenados em uma base de dados comum

• Execução fácil morta do padrão de observação via gatilhos. Existem muitos casos em que apenas alguns dados dependem de alguns outros dados e não afeta o aspecto IU da aplicação. Garantir a consistência pode ser muito difícil ou exigir muita programação. Claro, você poderia implementar comportamento do tipo gatilho com objectos, mas requer mais programação do que uma simples definição de SQL

Há boas respostas aqui. Vou tentar adicionar a minha opinião. Gosto de SQL, consigo pensar com facilidade. As consultas produzidas por camadas em cima do DB (como marcos ORM) são geralmente hediondas. Eles vão selecionar toneladas de coisas extras, juntar em coisas que você não precisa, etc.; tudo porque eles não sabem que você só quer uma pequena parte do objeto neste código. Quando você precisa de alto desempenho, muitas vezes você vai acabar entrando e usando pelo menos algumas consultas SQL personalizadas em um Sistema ORM só para acelerar alguns pontos de estrangulamento. Porquê o SQL? Como outros já disseram, É fácil para os humanos. Faz um bom menor denominador comum. Qualquer idioma pode fazer SQL e chamar clientes de linha de comando, se necessário, e eles são praticamente sempre uma boa biblioteca. A análise do SQL é ineficiente? Pouco. A gramática é bem estruturada, então não há toneladas de ambiguidades que fariam o trabalho do analisador realmente difícil. A coisa real é que a sobrecarga de analisar SQL basicamente, não é nada.

Digamos que você executa uma consulta como "selecione x da tabela onde id = 3", e então fazê-lo novamente com 4, depois 5, vezes sem conta. Nesse caso, a sobrecarga de análise pode existir. É por isso que você preparou declarações (como outros já mencionaram). O servidor analisa a consulta uma vez, e pode trocar nos 3 e 4 e 5 sem ter que Reparar tudo.

Mas esse é o caso trivial. Na vida real, o seu sistema pode juntar-se a 6 mesas e ter de puxar centenas de milhares de registos (se não mais). Pode ser uma consulta que você deixa correr em um banco de dados cluster por horas, porque essa é a melhor maneira de fazer as coisas em seu caso. Mesmo com uma consulta que leva apenas um minuto ou dois para executar, o tempo para analisar a consulta é essencialmente livre em comparação com a retirada de registros do disco e fazendo ordenação/agregação/etc. A sobrecarga de enviar o extt "LEFT OUTER JOIN ON" é apenas alguns bytes, em comparação com o envio de byte especial codificado 0x3F. mas quando o seu conjunto de resultados é de 30 MB (quanto mais gigs+), esses poucos bytes extras são inúteis em comparação com não ter que mexer com algum objeto de compilador de consulta especial.

Muitas pessoas usam SQL em pequenas bases de dados. O maior com quem interajo são apenas algumas dúzias de concertos. SQL é usado em tudo, desde pequenos arquivos (como o pequeno SQLite DBs pode ser) até grupos Oracle tamanho terabyte. Considerando que é poder, na verdade é um conjunto de comandos surpreendentemente simples e pequeno.

É um padrão omnipresente. Praticamente todas as linguagens de programação têm uma forma de aceder às bases de dados SQL. Tente isso com um protocolo binário proprietário. Todos sabem disso. Você pode encontrar especialistas facilmente, os novos desenvolvedores normalmente entendê-lo em algum grau sem precisar de treinamento
• a SQL está muito ligada ao modelo relacional, que tem sido explorada em termos de optimização e escalabilidade. Mas ainda requer manual ajustes (criação de índice, estrutura de consulta, etc.), que é relativamente fácil devido à interface textual.

Mas porquê usar a linguagem SQL para interacção com uma base de dados deste tipo?

Eu acho que é pela mesma razão que você usa uma linguagem legível (código fonte) humana para interação com o compilador.

Pessoalmente, eu teria usado algum bytecode' compiled db query', que seria montado uma vez dentro de uma aplicação cliente e passado para a base de dados.

Esta é uma característica existente (opcional) das bases de dados, chamada " armazenada procedimento".

---

Editar:

Ficaria muito grato se pudesse dar alguns exemplos em que o SQL é usado sem o ORM propositadamente, e por que

Quando implementei o meu próprio ORM, implementei o ORM framework usando ADO.NET: e usar ADO.NET inclui o uso de declarações SQL em sua implementação.

Depois de todas as edições e comentários, o ponto principal da sua pergunta parece ser : porque é que a natureza do SQL está mais perto de ser uma interface humano/base de dados do que de ser uma interface aplicação/base de dados ?

E a resposta muito simples para que pergunta é : porque isso é exatamente o que era originalmente destinado a ser.

Os predecessores de SQL (quel sendo presumivelmente o mais importante) tinham a intenção de ser exatamente isso: uma linguagem de consulta, ou seja, uma linguagem que não tinha nada de INSERT, UPDATE, DELETE.

Além disso, pretendia-se ser uma linguagem de consulta que poderia ser usada por qualquer usuário, desde que o usuário estivesse ciente da estrutura lógica do banco de dados, e obviamente sabia como expressar essa estrutura lógica na linguagem de consulta que ele estava usando.

As ideias originais por trás do QUEL / SQL eram que um banco de dados foi construído usando "qualquer mecanismo concebível", que o banco de dados" real " poderia ser realmente qualquer coisa (por exemplo, um único gigantesco Arquivo XML - allthough 'XML', não foi considerada uma opção válida no momento), e que não seria "algum tipo de máquinas", que compreendeu como transformar a estrutura real do que 'qualquer coisa' para a lógica de estrutura relacional como foi percebida pelo usuário do SQL.

O fato de que para realmente conseguir isso, as estruturas subjacentes são necessárias para se prestarem a "visualizá-las em relação", não foi entendido tão bem naqueles dias como é agora.

SIM, é irritante ter de escrever declarações SQL para armazenar e recuperar objectos.

É por isso que a Microsoft adicionou coisas como LINQ (language integrated query) em C# e VB.NET para tornar possível consultar bases de dados usando objetos e métodos em vez de strings.

A maioria das outras línguas tem algo similar com níveis variados de sucesso dependendo das habilidades dessa linguagem.

Por outro lado, é útil saber como funciona o SQL e acho que é é um erro proteger-se completamente dele. Se você usar o banco de dados sem pensar você pode escrever consultas extremamente ineficientes e indexar o banco de dados incorretamente. Mas uma vez que você entenda como usar o SQL corretamente e tenha ajustado seu banco de dados, você tem uma ferramenta muito poderosa testada e testada disponível para encontrar exatamente os dados que você precisa extremamente rapidamente.

A minha maior razão para a SQL é a apresentação de relatórios ad hoc. Esse relatório que os seus utilizadores de negócios querem, mas não sabem que precisam dele ainda.

O SQL é uma interface entre um ser humano e uma base de dados. A questão é: por que fazer temos que usá-lo para interacção aplicação / base de dados? I ainda pedir exemplos de seres humanos a gravar / a depurar o SQL.

Uso muito sqlite desde as tarefas mais simples (como registar os meus registos de firewall directamente numa base de dados sqlite) até às tarefas mais complexas de análise e depuração na minha pesquisa diária. Colocar meus dados em tabelas e escrever consultas SQL para munge-los em maneiras interessantes parecem-me ser a coisa mais natural nestas situações.

No seu ponto sobre porque é que ainda é usado como interface entre a aplicação/base de dados, este é o meu raciocínio simples:

1. Há cerca de 3-4 décadas de investigação séria neste domínio a partir de 1970 com a seminal de Codd artigo sobre álgebra relacional. A álgebra relacional forma o bases matemáticas para SQL (e outras QLs), embora o SQL não siga completamente a relacional modelo.

2. A forma" texto " da língua (além de ser fácil compreensível para os seres humanos) é também fácil de processar por máquinas (say usar um analisador de gramática como o lex) e é facilmente convertível para qualquer "bytecode" usando qualquer número de otimizações.

3. Não tenho certeza se fazer isso em qualquer outra maneira teria rendido benefícios convincentes nos casos genéricos. Caso contrário, provavelmente teria sido descoberto. e adoptado nas 3 décadas de pesquisa. O SQL provavelmente fornece o os melhores resultados ao fazer a ponte dividir entre humanos / bases de dados e aplicações / bases de dados.

A pergunta que então se torna interessante de se perguntar é, "Quais são os benefícios reais de fazer SQL em qualquer outra maneira "não-texto"?"Será google para isso agora:)

SQL é uma interface comum usada pela plataforma DBMS - o ponto inteiro da interface é que todas as operações de banco de dados podem ser especificadas em SQL sem necessitar de chamadas API suplementares. Isto significa que existe uma interface comum entre todos os clientes do software de aplicação do sistema, relatórios e ferramentas de consulta ad - hoc.

Em segundo lugar, o SQL torna-se cada vez mais útil à medida que as consultas se tornam mais complexas. Tente usar o LINQ para especificar uma junção de 12 vias a com três condições baseadas no existencial predicados e uma condição baseada em um agregado calculado em uma subquery. Este tipo de coisa é razoavelmente compreensível em SQL, mas é improvável que seja possível em uma ORM.

Em muitos casos, uma ORM fará 95% do que você quer - a maioria das consultas emitidas pelas aplicações são simples operações CRUD que um ORM ou outro mecanismo genérico de interface de banco de dados pode lidar facilmente. Algumas operações são melhor feitas usando código SQL personalizado.

No entanto, os ORMs não são a base de dados. interface. Fowler's Patterns of Enterprise Application Architecture has quite a good section on other types of database access strategy with some discussion of the merits of each.

Há muitas vezes boas razões para não usar um ORM como a camada de interface de base de dados primária. Um exemplo de um bom é que bibliotecas de banco de dados plataforma como ADO.Net muitas vezes fazer um bom trabalho e se integrar bem com o resto do ambiente. Você pode achar que o ganho de usar algum outro a interface não supera os benefícios da integração.

No entanto, a razão final pela qual você não pode realmente ignorar o SQL é que você está finalmente trabalhando com um banco de dados se você está fazendo uma aplicação de banco de dados. Há muitas, muitas histórias do WTF sobre erros no código de aplicação comercial feito por pessoas que não entenderam as bases de dados corretamente. Um código de banco de dados mal pensado pode causar problemas de tantas maneiras, e alegremente pensando que você não precisa entender como o DBMS funciona é um ato de arrogância que é obrigado a vir e morder-te um dia. Pior ainda, virá morder outro pobre coitado que herda o teu código.

Enquanto vejo o seu ponto de vista, a linguagem de consulta do SQL tem um lugar, especialmente em grandes aplicações com um monte de dados. E para apontar o óbvio, se a linguagem não estava lá, você não poderia chamá-lo de SQL (linguagem de consulta estruturada). O benefício de ter SQL sobre o método que você descreveu é SQL é geralmente muito legível, embora alguns realmente empurram os limites em suas consultas.

Concordo plenamente com o Mark Byers, não se deve proteger do SQL. Qualquer programador pode escrever SQL, mas para realmente fazer a sua aplicação funcionar bem com a interação SQL, compreender a linguagem é uma obrigação.

Se tudo foi pré-completado com bytecode como você descreveu, eu odiaria ser o único a ter que depurar a aplicação após o desenvolvedor original sair (ou mesmo depois de não ver o código por 6 meses).

Acho que a premissa da pergunta é incorreta. Esse SQL pode ser representado como texto é imaterial. A maioria dos bancos de dados modernos só compilaria consultas uma vez e cache-os de qualquer maneira, então você já tem efetivamente um 'compilado bytecode'. E não há razão para isto não acontecer em relação aos clientes, embora não tenha a certeza se alguém o fez. Você disse que SQL é uma mensagem de texto, bem, eu penso nele como um mensageiro, e, como sabemos, não atire no mensageiro. A verdadeira questão é que as relações não são uma forma suficientemente boa de organizar dados do mundo real. SQL é só batom no porco.

Se a primeira parte parece referir - se ao que é normalmente chamado de impedância de Mapeamento Objeto-Relacional. Já existem muitos quadros para aliviar esse problema. Também há lojas. Algumas coisas serão mais fáceis, outras ficarão mais complexas, mas no caso geral elas funcionam bem se você puder pagar a camada extra.

Na segunda parte você parece reclamar sobre o SQL ser texto (ele usa strings em vez de ids, etc)... SQL is a query language . As a linguagem (computador ou outra coisa) que se pretende ler ou escrever pelos humanos é o texto orientado para essa matéria. Montagem, C, PHP, tudo. Por quê? Porque, bem... faz sentido, não faz?

Se quiser consultas pré-completas, já tem procedimentos armazenados. Declarações preparadas também são compiladas uma vez no ar, IIRC. A maioria (se não todos) dos drivers db conversam com o servidor de banco de dados usando um protocolo binário de qualquer maneira.

Sim, o texto é um pouco ineficiente. Mas, na verdade, obter os dados é muito mais caro, então o SQL baseado no texto é razoavelmente insignificante.

O SQL foi criado para fornecer uma interface para fazer consultas ad hoc contra uma base de dados relacional.

Em geral, a maioria das bases de dados relacionais compreende alguma forma de SQL.

Existem bases de dados orientadas a objectos, e (presumivelmente) usam objectos para fazer as suas perguntas... mas pelo que sei, as bases de dados têm muito mais ouvido, e as bases de dados relacionais funcionam muito bem.

As bases de Dados Relacionais também permitem que você opere em um estado" desconectado". Uma vez que você tem o informações que você pediu, você pode fechar a conexão da base de dados. Com um banco de dados OO, você ou precisa devolver todos os objetos relacionados com o atual (e os que eles estão relacionados... e o..... etc...) ou reabrir a conexão para recuperar novos objetos à medida que eles são acessados.

Além de SQL, você também tem ORMs (mapeamentos objeto-relacional) que mapeiam objetos para SQL e para trás. Existem alguns deles, incluindo LINQ (. Net), O MS Entity Framework (. net), Hibernate (Java), SQLAlchemy( Python), ActiveRecord (Ruby), Classe::DBI (Perl), etc...

Uma linguagem de banco de dados é útil porque fornece um modelo lógico para os seus dados, independentemente de quaisquer aplicações que o usem. SQL tem um monte de deficiências, no entanto, não sendo o menos importante que a sua integração com outras línguas é pobre, suporte tipo é cerca de 30 anos atrás do resto da indústria e nunca foi uma linguagem verdadeiramente relacional de qualquer maneira.

O SQL sobreviveu principalmente porque o mercado de bases de dados foi e continua a ser dominado pelos três mega-fornecedores que têm um interesse adquirido em proteger o seu investimento. Isso está mudando e os dias do SQL estão provavelmente numerados, mas o modelo que finalmente irá substituí - lo provavelmente ainda não chegou-embora haja muitos candidatos por estes dias.

Acho que a maioria das pessoas não está a perceber a tua pergunta, embora eu ache que é muito claro. Infelizmente não tenho a resposta "correcta". Acho que é uma combinação de várias coisas:

1. decisões Semi-arbitrárias quando foram concebidas como facilidade de Utilização, não necessitando de um compilador SQL (ou IDE), portabilidade, etc.
Por acaso, pescava bem (provavelmente por razões semelhantes) E agora devido a razões históricas (compatibilidade, bem conhecida, comprovada, etc.) continua a ser usado. Acho que a maioria das empresas não se preocupou com outra solução porque funciona bem, não é um estrangulamento, é um padrão, blá, blá..

Um dos princípios de design Unix pode ser dito Assim, " escrever programas para lidar com fluxos de texto, porque isso é uma interface universal.".

E isso, EU ACREDITO, é por isso que normalmente usamos SQL em vez de alguns 'byte-SQL' que só tem uma interface de compilação. Mesmo se nós tivéssemos um byte-SQL, alguém escreveria um "texto SQL", e o loop estaria completo.

Além disso, MySQL e SQLite são menos completos do que, digamos, MSSQL e Oracle SQL. Então ainda estás em baixo fim da piscina SQL.

Na verdade, existem algumas bases de dados não SQL (como objectividade, Oracle Berkeley DB, etc.) os produtos vieram, mas nenhum deles conseguiu. No futuro, se alguém encontrar uma alternativa intuitiva para SQL, isso irá responder à sua pergunta.

Existem muitos sistemas de bases de dados não relacionais. Aqui estão apenas alguns: Memcached Gabinete De Tóquio

Quanto a encontrar uma base de dados relacional que não use SQL como interface primária, acho que não a encontrará. Razão: SQL é uma ótima maneira de falar sobre relações. Não consigo entender por que isso é importante para você: se você não gosta de SQL, coloque uma abstração sobre ele (como um ORM) para que você não tenha que se preocupar com isso. Deixa a abstração preocupar-se com isso. Leva-te ao mesmo sítio.

No entanto, o problema que o teu realmente mencionar aqui é a relação de objectos desconectar - o problema é com a própria relação. Objetos e tuplas relacionais nem sempre se prestam a ser uma relação 1-1, que é a razão pela qual um desenvolvedor pode frustrar-se com um banco de dados. A solução para isso é usar um tipo de banco de dados diferente.

Porque muitas vezes, você não pode ter certeza de que (citando você) "Ninguém nunca visto após a implantação" . Saber que há uma interface fácil para relatórios e para pesquisa de nível de DataSet é um bom caminho para a evolução do seu aplicativo.
Você está certo, que existem outras soluções que podem ser válidas em algumas situações: XML, arquivos de texto simples, OODB...
Mas ter um conjunto de interfaces comuns (como ODBC) é uma grande vantagem para a vida dos dados.

Acho que a razão pode ser os algoritmos de busca/busca/captura para os quais a laungage sql está ligada. Lembre - se que o sql foi desenvolvido por 40 anos-e o objetivo tem sido tanto o sábio preformence quanto o usuário firenly sábio.

Pergunte - se Qual é a melhor maneira de encontrar 2 attilos. Agora, por que investigar que cada vez que você gostaria de fazer algo que inclui que cada vez que você desenvolver a sua aplicação. Assumindo que o objetivo principal é o desenvolvimento de sua aplicação quando desenvolver uma aplicação.

Uma aplicação tem semelhanças com outras aplicações, uma base de dados tem semelhanças com outras bases de dados. Então deve haver uma "melhor maneira" de interagir, logicamente.

Pergunte-se também como desenvolveria uma melhor aplicação apenas para consola que não utilize o SQL laungage. Se você não pode fazer isso eu acho que você precisa desenvolver um novo tipo de GUI que são ainda mais fundamentalmente mais fáceis de usar do que com um console - para desenvolver coisas a partir dele. E isso pode ser possível. Mas ainda a maioria do desenvolvimento de aplicativos é baseado em torno de console e digitação.

Então quando se trata de laungage eu não acho que você pode fazer um laungage de texto muito mais fundamentalmente mais fácil do que sql. E lembre - se que cada palavra de qualquer coisa está inseperatly conectada ao seu significado - se você remover o Significado a palavra não pode ser usada-se você remover a palavra você não pode comunicar o significado. Você não tem nada com que descrevê-lo (e talvez você não pode nem mesmo acho que seria divertido estar ligado a qualquer outra coisa que já pensaste...).

Então, basicamente, os melhores algoritmos possíveis para manipulação de banco de dados são atribuídos a palavras - se você remover essas palavras você terá que atribuir essas manipulações algo mais - e o que seria isso?

Acho que podes usar o ORM

Se e apenas se souber o básico de sql.

Caso contrário, o resultado não é o melhor.