Por que não gosta de SQL? [fechadas]

Tenho ouvido muito ultimamente que SQL é uma linguagem terrível, e parece que todo framework sob o sol vem pré-empacotado com uma camada de abstração de banco de dados.

Porém, em minha experiência, SQL é frequentemente a maneira muito mais fácil, mais versátil e mais amigável para o programador de gerenciar a entrada e saída de dados. Cada camada de abstração que usei parece ser uma abordagem marcadamente limitada, sem nenhum benefício real.

O que torna o SQL tão terrível e por que as camadas de abstração do banco de dados são valiosas?

Isso é parcialmente subjetivo. Então esta é minha opinião:

SQL tem um estilo de linguagem pseudo-natural . Os inventores acreditam que podem criar uma linguagem como o inglês e que as consultas ao banco de dados serão muito simples. Um erro terrível. SQL é muito difícil de entender, exceto em casos triviais.

SQL é declarativo. Você não pode dizer ao banco de dados como ele deve fazer as coisas, apenas o que você deseja como resultado. Isso seria perfeito e muito poderoso - se você não tivesse que se preocupar com o desempenho. Então você acaba escrevendo SQL - lendo planos de execução - reformulando SQL tentando influenciar o plano de execução, e você se pergunta por que não consegue escrever o plano de execução sozinho .

Outro problema da linguagem declarativa é que alguns problemas são mais fáceis de resolver de maneira imperativa. Portanto, você pode escrever em outra linguagem (você precisará do SQL padrão e provavelmente de uma camada de acesso a dados) ou usando extensões de linguagem específicas do fornecedor, digamos, escrevendo procedimentos armazenados e semelhantes. Ao fazer isso, você provavelmente descobrirá que está usando uma das piores linguagens que já viu - porque ela nunca foi projetada para ser usada como uma linguagem imperativa.

SQL é muito antigo . O SQL foi padronizado, mas tarde demais, muitos fornecedores já desenvolveram suas extensões de linguagem. Portanto, o SQL acabou em dezenas de dialetos. É por isso que os aplicativos não são portáteis e uma razão para ter uma camada de abstração de banco de dados.

Mas é verdade - não há alternativas viáveis. Portanto, todos nós usaremos o SQL nos próximos anos.

Além de tudo o que foi dito, uma tecnologia não precisa ser ruim para tornar uma camada de abstração valiosa .

Se você estiver fazendo um script ou aplicativo muito simples, poderá misturar chamadas SQL em seu código onde quiser. No entanto, se você estiver fazendo um sistema complexo, isolar as chamadas de banco de dados em módulo (s) separado (s) é uma boa prática e, portanto, isolar seu código SQL. Ele melhora a legibilidade, manutenção e testabilidade do seu código. Ele permite que você adapte rapidamente seu sistema às mudanças no modelo de banco de dados sem quebrar todas as coisas de alto nível, etc.

SQL é ótimo. As camadas de abstração sobre ele o tornam ainda maior!

Um ponto das camadas de abstração é o fato de que as implementações de SQL tendem a ser mais ou menos incompatíveis umas com as outras, já que o padrão é ligeiramente ambíguo e também porque a maioria dos fornecedores adicionou seus próprios extras (não padrão) lá. Ou seja, o SQL escrito para um banco de dados MySQL pode não funcionar da mesma forma com, digamos, um banco de dados Oracle - mesmo que "devesse".

Eu concordo, porém, que o SQL é muito melhor do que a maioria das camadas de abstração que existem. Não é culpa do SQL estar sendo usado para coisas para as quais não foi projetado.

SQL é criticado por várias fontes:

• Programadores que não se sentem confortáveis ​​com nada além de uma linguagem imperativa.
• Consultores que lidam com muitos produtos incompatíveis baseados em SQL diariamente
• Fornecedores de banco de dados não relacionais tentando quebrar o domínio dos fornecedores de banco de dados relacional no mercado
• Especialistas em bancos de dados relacionais, como Chris Date, que consideram as implementações atuais de SQL insuficientes

Se você se limitar a um produto DBMS, então eu definitivamente concordo que os bancos de dados SQL são mais versáteis e de maior qualidade do que seus concorrentes, pelo menos até que você atinja uma barreira de escalabilidade intrínseca ao modelo. Mas você está realmente tentando escrever o próximo Twitter ou apenas tentando manter alguns dados contábeis organizados e consistentes?

A crítica ao SQL é freqüentemente um substituto para as críticas aos RDBMSs. O que os críticos dos RDBMSs parecem não entender é que eles resolvem muito bem uma enorme classe de problemas de computação e que estão aqui para tornar nossas vidas mais fáceis, não mais difíceis.

Se eles realmente quisessem criticar o próprio SQL, eles apoiariam esforços como o Tutorial D e o Dataphor.

Não é tão terrível. É uma tendência infeliz neste setor de descartar a tecnologia confiável anterior quando um novo "paradigma" surge. No final do dia, esses frameworks muito provavelmente estão usando SQL para se comunicar com o banco de dados, então como pode ser TÃO ruim? Dito isso, ter uma camada de abstração "padrão" significa que um desenvolvedor pode se concentrar no código do aplicativo e não no código SQL. Sem essa camada padrão, você provavelmente escreveria uma leve cada vez que estivesse desenvolvendo um sistema, o que é uma perda de esforço.

SQL é projetado para gerenciamento e consulta de dados baseados em SET. Muitas vezes é usado para fazer mais e casos extremos às vezes levam à frustração.

O USO real de SQL pode ser TÃO impactado pelo design do banco de dados base que o SQL pode não ser o problema, mas o design pode - e quando você joga o código legado associado a um design ruim, as mudanças são mais impactantes e caras de implementar ( ninguém gosta de voltar e "consertar" coisas que estão "funcionando" e atingindo os objetivos)

Os carpinteiros podem bater pregos com martelos, serrar madeira com serras e alisar tábuas com aviões. É possível "serrar" usando martelos e aviões, mas dang, é frustrante.

Não direi que é terrível. Não é adequado para algumas tarefas. Por exemplo: você não pode escrever um bom código procedural com SQL. Certa vez, fui forçado a trabalhar com manipulação de conjuntos com SQL. Levei um fim de semana inteiro para descobrir isso.

SQL foi projetado para álgebra relacional - é onde deve ser usado.

Tenho ouvido muito ultimamente que SQL é uma linguagem terrível, e parece que todo framework sob o sol vem pré-empacotado com uma camada de abstração de banco de dados.

Observe que essas camadas apenas convertem suas próprias coisas em SQL. Para a maioria dos fornecedores de banco de dados, SQLé a única maneira de se comunicar com o mecanismo.

Porém, em minha experiência, SQL é frequentemente a maneira muito mais fácil, mais versátil e mais amigável para o programador de gerenciar a entrada e saída de dados. Cada camada de abstração que usei parece ser uma abordagem marcadamente limitada, sem nenhum benefício real.

… Razão que acabei de descrever acima.

As camadas do banco de dados não adicionam nada, apenas limitam você. Eles tornam as consultas mais simples, mas nunca mais eficientes.

Por definição, não há nada nas camadas do banco de dados que não esteja em SQL.

O que é SQLtão terrível e por que as camadas de abstração do banco de dados são valiosas?

SQL é uma boa linguagem, no entanto, é preciso um pouco do cérebro para trabalhar com ela.

Em teoria, SQL é declarativo, ou seja, você declara o que deseja obter e a engine fornece da maneira mais rápida possível.

Na prática, existem muitas maneiras de formular uma consulta correta (ou seja, a consulta que retorna resultados corretos).

Os otimizadores são capazes de construir um castelo de Lego a partir de alguns algoritmos predefinidos (sim, eles são múltiplos), mas eles simplesmente não podem fazer novos algoritmos. Ainda é preciso um SQLdesenvolvedor para ajudá-los.

No entanto, algumas pessoas esperam que o otimizador produza "o melhor plano possível", não "o melhor plano disponível para esta consulta com determinada implementação do SQL mecanismo".

E como todos sabemos, quando o programa de computador não atende às expectativas das pessoas, é o programa que leva a culpa, não as expectativas.

Na maioria dos casos, entretanto, a reformulação de uma consulta pode produzir o melhor plano possível. Existem tarefas quando é impossível, no entanto, com as melhorias novas e crescentes paraSQL esses casos, cada vez menos.

Seria bom, entretanto, se os fornecedores fornecessem algum acesso de baixo nível às funções como "obter o intervalo do índice", "obter uma linha pelo rowid" etc., como os Ccompiladores permitem que você insira o assembly diretamente na linguagem.

Recentemente escrevi um artigo sobre isso no meu blog:

• Pensamento duplo em SQL

Sou um grande defensor do ORM e ainda acredito que o SQL é muito útil, embora seja certamente possível fazer coisas terríveis com ele (como qualquer outra coisa). .

Eu vejo o SQL como uma linguagem supereficiente que não tem como prioridades a reutilização de código ou a capacidade de manutenção / refatoração.

Portanto, o processamento extremamente rápido é a prioridade. E isso é aceitável. Você apenas tem que estar ciente das compensações, que para mim são consideráveis.

De um ponto de vista estético, como uma linguagem, sinto que faltam algumas coisas, já que não tem conceitos OO e assim por diante - parece um código de procedimento muito antigo para mim. Mas é de longe a maneira mais rápida de fazer certas coisas, e esse é um nicho poderoso!

Eu diria que uma camada de abstração de banco de dados incluída com um framework é uma coisa boa porque resolve dois problemas muito importantes:

1. Ele mantém o código distinto. Ao colocar o SQL em outra camada, que geralmente é muito fina e deve fazer apenas o básico de consulta e entrega de resultados (de maneira padronizada), você mantém seu aplicativo livre da confusão de SQL. É a mesma razão pela qual os desenvolvedores da web (deveriam) colocar CSS e Javascript em arquivos separados. Se você puder evitar, não misture seus idiomas .

2. Muitos programadores são simplesmente ruins no uso de SQL. Por alguma razão, um grande número de desenvolvedores (especialmente desenvolvedores da web) parecem ser muito, muito ruins no uso de SQL ou RDBMS em geral. Eles tratam o banco de dados (e o SQL por extensão) como o pequeno e sujo intermediário pelo qual precisam passar para obter os dados. Isso leva a bancos de dados extremamente mal planejados, sem índices, tabelas empilhadas em cima de tabelas de maneiras duvidosas e consultas muito mal escritas. Ou pior, eles tentam ser muito gerais (Sistema Especializado, alguém?) E não podem relacionar os dados de forma significativa.

Infelizmente, às vezes a maneira como alguém tenta resolver um problema e as ferramentas que usa, seja por ignorância, teimosia ou algum outro traço, estão em oposição direta entre si, e boa sorte tentando convencê-los disso. Como tal, além de ser apenas uma boa prática, considero uma camada de abstração de banco de dados uma espécie de rede de segurança, pois não só mantém o SQL fora dos olhos do pobre desenvolvedor, mas torna seu código significativamente mais fácil de refatorar, uma vez que todas as consultas estão em um só lugar.

SQL é excelente para certos tipos de tarefas, especialmente manipular e recuperar conjuntos de dados.

No entanto, o SQL está faltando (ou apenas implementa parcialmente) várias ferramentas importantes para gerenciar mudanças e complexidade:

• Encapsulamento : os mecanismos de encapsulamento de SQL são grosseiros. Ao escrever código SQL, você deve saber tudo sobre a implementação de seus dados. Isso limita a quantidade de abstração que você pode alcançar.

• Polimorfismo : se você quiser realizar a mesma operação em tabelas diferentes, terá que escrever o código duas vezes. (Pode-se atenuar isso com o uso criativo de visualizações.)

• Controle de visibilidade : não existe um mecanismo SQL padrão para ocultar partes do código umas das outras ou agrupá-las em unidades lógicas, de forma que cada tabela, procedimento, etc. seja acessível de todos os outros, mesmo quando for indesejável.

• Modularidade e controle de versão

Finalmente, codificar manualmente as operações CRUD em SQL (e escrever o código para conectá-lo ao restante do aplicativo) é repetitivo e sujeito a erros.

Uma camada de abstração moderna fornece todos esses recursos e nos permite usar SQL onde é mais eficaz, ao mesmo tempo que esconde os detalhes de implementação repetitivos e disruptivos. Ele fornece ferramentas para ajudar a superar a incompatibilidade de impedância relacional de objeto que complica o acesso a dados no desenvolvimento de software orientado a objetos.

O SQL é baseado na Teoria dos Conjuntos, enquanto a maioria das linguagens de alto nível são orientadas a objetos atualmente. Os programadores de objetos normalmente gostam de pensar em objetos e precisam fazer uma mudança mental para usar ferramentas baseadas em Set para armazenar seus objetos. Geralmente, é muito mais natural (para o programador OO) apenas cortar o código na linguagem de sua escolha e fazer algo como object.save ou object.delete no código do aplicativo em vez de ter que escrever consultas sql e chamar o banco de dados para alcançar o mesmo resultado.

É claro que, às vezes, para coisas complexas, o SQL é mais fácil de usar e mais eficiente, por isso é bom ter domínio sobre os dois tipos de tecnologia.

IMO, o problema que vejo que as pessoas têm com SQL não tem nada a ver com design relacional nem com a linguagem SQL em si. Tem a ver com a disciplina de modelar a camada de dados, que em muitos aspectos é fundamentalmente diferente da modelagem de uma camada ou interface de negócios. Erros na modelagem na camada de apresentação são geralmente muito mais fáceis de corrigir do que na camada de dados, onde você tem vários aplicativos usando o banco de dados. Esses problemas são os mesmos encontrados na modelagem de uma camada de serviço em designs SOA, em que você deve levar em conta os consumidores atuais de seu serviço e os contratos de entrada e saída.

O SQL foi projetado para interagir com modelos de banco de dados relacionais. Existem outros modelos de dados que já existem há algum tempo, mas a disciplina sobre como projetar a camada de dados adequadamente existe independentemente do modelo teórico usado e, portanto, as dificuldades que os desenvolvedores normalmente têm com SQL estão geralmente relacionadas a tentativas de impor uma modelo de dados em um produto de banco de dados relacional.

Por um lado, eles tornam trivial o uso de consultas parametrizadas, protegendo você de ataques de injeção de SQL. Usar SQL bruto, dessa perspectiva, é mais arriscado, ou seja, mais fácil errar do ponto de vista da segurança. Frequentemente, eles também apresentam uma perspectiva orientada a objetos em seu banco de dados, o que dispensa a tradução.

Ouviu muito recentemente? Espero que você não esteja confundindo isso com o movimento NoSql. Pelo que eu sei, muitas pessoas usam o NoSql para aplicativos da web de alta escalabilidade e parecem ter esquecido que o SQL é uma ferramenta eficaz em um cenário de não "aplicativo da web de alta escalabilidade".

O negócio da camada de abstração trata apenas de classificar a diferença entre o código orientado a objetos e o código baseado em conjunto de tabelas, como o SQL gosta de falar. Normalmente, isso resulta na gravação de muitos clichês e código de transição maçante entre os dois. ORM automatiza isso e, portanto, economiza tempo para pessoas objetivas de negócios.

Para programadores SQL experientes, os lados ruins são

• Verbosidade
• Como muitos já disseram aqui, o SQL é declarativo, o que significa que a otimização não é direta . É como um rali em comparação com uma corrida em circuito.
• Frameworks que tentam abordar todos os dialetos possíveis e não suportam atalhos de nenhum deles
• Nenhum controle de versão fácil.

Para outros, as razões são que

• alguns programadores são ruins em SQL. Provavelmente porque o SQL opera com conjuntos, enquanto as linguagens de programação funcionam no paradigma de objeto ou funcional. Pensar em conjuntos (união, produto, intersecção) é uma questão de hábito que algumas pessoas não têm.
• algumas operações não são autoexplicativas: ou seja, a princípio não está claro onde e tendo conjuntos de filtros diferentes.
• existem muitos dialetos

O principal objetivo dos frameworks SQL é reduzir a digitação. De alguma forma, eles o fazem, mas frequentemente apenas para consultas muito simples. Se você tentar fazer algo complexo, terá que usar strings e digitar muito. Frameworks que tentam lidar com tudo que é possível, como SQL Alchemy, tornam-se muito grandes, como outra linguagem de programação.

[atualização em 26.06.10] Recentemente, trabalhei com o módulo Django ORM . Este é o único framework SQL digno que eu vi. E este torna muito mais fácil trabalhar com as coisas. Agregados complexos são um pouco mais difíceis.

SQL não é uma linguagem terrível, às vezes não funciona muito bem com outras pessoas.

Se, por exemplo, você tiver um sistema que deseja representar todas as entidades como objetos em alguma linguagem OO ou outra, então combinar isso com SQL sem qualquer tipo de camada de abstração pode se tornar um tanto complicado. Não há uma maneira fácil de mapear uma consulta SQL complexa no mundo OO. Para aliviar a tensão entre esses mundos, camadas adicionais de abstração são inseridas (um mapeador OR, por exemplo).

SQL é uma linguagem muito boa para manipulação de dados. Do ponto de vista do desenvolvedor, o que eu não gosto é que mudar o banco de dados não quebra o seu código em tempo de compilação ... Então eu uso abstrações que adicionam esse recurso ao preço do desempenho e talvez da expressividade da linguagem SQL , porque na maioria dos aplicativos você não precisa de tudo o que o SQL possui.

A outra razão pela qual o SQL é odiado é por causa dos bancos de dados relacionais.

O teorema CAP se torna popular:

Que objetivos você deseja de um sistema de dados compartilhados?

• Consistência forte: todos os clientes têm a mesma visão, mesmo na presença de atualizações
• Alta disponibilidade: todos os clientes podem encontrar alguma réplica dos dados, mesmo na presença de falhas
• Tolerância de partição: as propriedades do sistema são mantidas mesmo quando o sistema é particionado

O teorema afirma que você sempre pode ter apenas duas das três propriedades CAP ao mesmo tempo

Endereço de banco de dados relacional Strong Consistency and Partition-Tolerance.

Assim, mais e mais pessoas percebem que o banco de dados relacional não é a solução mágica, e mais e mais pessoas começam a rejeitá-lo em favor da alta disponibilidade, porque a alta disponibilidade torna o escalonamento horizontal mais fácil. A escala horizontal ganha popularidade porque atingimos o limite da lei de Moore , então a melhor maneira de dimensionar é adicionar mais máquina.

Se o banco de dados relacional for rejeitado, o SQL também será rejeitado.

O SQL tem muitas falhas, como alguns outros participantes aqui apontaram. Ainda assim, prefiro usar SQL em vez de muitas das ferramentas que as pessoas oferecem como alternativas, porque as "simplificações" costumam ser mais complicadas do que aquilo que deveriam simplificar.

Minha teoria é que o SQL foi inventado por um bando de esquiadores azuis em torres de marfim. Toda a estrutura não procedimental. Parece ótimo: diga-me o que você quer, em vez de como você deseja fazer. Mas, na prática, geralmente é mais fácil simplesmente dar os passos. Freqüentemente, isso parece tentar dar instruções de manutenção do carro, descrevendo como ele deve se comportar quando você terminar. Sim, você poderia dizer: "Eu quero que o carro faça mais uma vez 30 milhas por galão e corra com este zumbido como este ... hmmmm ... e etc." Mas não seria mais fácil para todos? basta dizer: "Substitua as velas de ignição"? E mesmo quando você descobre como expressar uma consulta complexa em termos não procedimentais, o mecanismo de banco de dados geralmente apresenta um plano de execução muito ineficiente para chegar lá.

E o tratamento de nulos me deixa louco! Sim, teoricamente, deve ter soado ótimo quando alguém disse: "Ei, se nulo significa desconhecido, então adicionar um valor desconhecido a um valor conhecido deveria resultar em um valor desconhecido. Afinal, por definição, não temos ideia de qual é o valor desconhecido . " Teoricamente, absolutamente verdade. Na prática, se temos 10.000 clientes e sabemos exatamente quanto dinheiro 9.999 nos deve, mas há alguma dúvida sobre o valor devido pelo último, e a administração diz: "Qual é o total de nossas contas a receber?", Sim, matematicamente correto a resposta é "não sei". Mas a resposta prática é "calculamos $ 4.327.287,42, mas há uma conta em questão, então esse número não é exato". Tenho certeza de que a administração prefere obter um número fechado, senão certo, do que um olhar vazio.

Dito isso, eu ainda prefiro usar SQL do que alguma camada construída sobre SQL, que apenas cria um outro conjunto de coisas que eu preciso aprender, e então eu tenho que saber que no final das contas isso será traduzido para SQL, e às vezes Posso apenas confiar que ele fará a tradução correta e eficientemente, mas quando as coisas ficam complexas eu não consigo, então agora eu tenho que conhecer a camada extra, ainda preciso saber SQL e como isso vai traduzir para que eu possa enganar a camada fazendo com que o SQL faça a coisa certa. Arggh.

• Cada fornecedor estende a sintaxe SQL para atender às suas necessidades. Portanto, a menos que você esteja fazendo coisas bastante simples, seu código SQL não é portátil.

• A sintaxe do SQL não é ortogonal; por exemplo, as instruções select, insert, update,e deletetodas têm estruturas sintáticas completamente diferentes.

Eu concordo com seus pontos, mas para responder sua pergunta, uma coisa que torna o SQL tão "terrível" é a falta de padronização completa do T-SQL entre os fornecedores de banco de dados (Sql Server, Oracle etc.), o que torna o código SQL improvável de ser completamente portátil. As camadas de abstração do banco de dados resolvem esse problema, embora com um custo de desempenho (às vezes muito grave).

Viver com SQL puro pode realmente ser um inferno de manutenção. Para mim, a maior vantagem dos ORMs é a capacidade de refatorar código com segurança sem procedimentos tediosos de "refatoração de banco de dados". Existem boas estruturas de teste de unidade e ferramentas de refatoração para linguagens OO, mas ainda tenho que ver a contraparte de Resharper para SQL, por exemplo.

Mesmo assim, todos os DALs têm SQL nos bastidores e você precisa saber disso para entender o que está acontecendo com seu banco de dados, mas trabalhar diariamente com uma boa camada de abstração se torna mais fácil.

Se você não usou muito o SQL, acho que o maior problema é a falta de boas ferramentas de desenvolvedor.

Se você tem muita experiência com SQL, terá, em um ponto ou outro, se frustrado com a falta de controle sobre o plano de execução. Este é um problema inerente à maneira como o SQL foi especificado para os fornecedores. Acho que o SQL precisa se tornar uma linguagem mais robusta para realmente aproveitar a tecnologia subjacente (que é muito poderosa).

Rápido, escreva-me SQL para paginar um conjunto de dados que funcione em MySQL, Oracle, MSSQL, PostgreSQL e DB2.

Ah, certo, o SQL padrão não define nenhum operador para limitar o número de resultados retornados e em qual linha começar.

Não há amor por SQL porque SQL é ruim em sintaxe, semântica e uso atual. Eu vou explicar:

• sua sintaxe é um estilhaço de cobol, todas as críticas de cobol se aplicam aqui (em menor grau, para ser justo). Tentar ser uma linguagem natural sem realmente tentar interpretar a linguagem natural cria uma sintaxe arbitrária (é DROP TABLE ou DROP, UPDATE TABLE, UPDATE ou UPDATE IN, DELETE ou DELETE FROM ...) e monstruosidades sintáticas como SELECT (quantas páginas faz preenche?)
• a semântica também é profundamente falha, Date a explica em grandes detalhes, mas será suficiente observar que uma lógica booleana de três valores não se encaixa realmente em uma álgebra relacional onde uma linha pode apenas ser ou não parte de uma tabela
• ter uma linguagem de programação como a interface principal (e muitas vezes única) para bancos de dados provou ser uma escolha muito ruim e criou uma nova categoria de falhas de segurança

Eu concordaria com a maioria das postagens aqui que o debate sobre a utilidade do SQL é principalmente subjetivo, mas acho que é mais subjetivo na natureza das suas necessidades de negócios.

Linguagens declarativas, como Stefan Steinegger apontou, são boas para especificar o que você quer, não como você quer fazer. Isso significa que suas várias implementações de SQL são decentes de uma perspectiva de alto nível: ou seja, se tudo o que você deseja é obter alguns dados e nada mais importa, você pode se satisfazer escrevendo consultas relativamente simples e escolhendo a implementação de SQL isso é certo para você.

Se você trabalha em um nível muito "inferior" e precisa otimizar tudo isso sozinho, está longe de ser o ideal. Usar uma camada adicional de abstração pode ajudar, mas se o que você realmente está tentando fazer é especificar os métodos para otimizar as consultas e assim por diante, é um pouco contra intuitivo adicionar um intermediário ao tentar otimizar.

O maior problema que tenho com SQL é como outras linguagens "padronizadas", existem muito poucos padrões reais. Eu quase preferiria ter que aprender uma linguagem totalmente nova entre Sybase e MySQL para não confundir as duas convenções.

Embora o SQL faça o trabalho, certamente tem problemas ...

• tenta ser simultaneamente o nível alto e a abstração de baixo nível , e isso é ... estranho. Talvez devessem ser dois ou mais padrões em níveis diferentes.
• é um grande fracasso como padrão . Muitas coisas dão errado quando um padrão ou mexe com tudo, exige muito de implementações, pede muito pouco ou, por alguma razão, não atinge o objetivo parcialmente social de motivar fornecedores e implementadores a produzir implementações completas interoperáveis ​​em conformidade. Você certamente não pode dizer que o SQL fez nada disso. Olhe para alguns outros padrões e observe que o sucesso ou o fracasso do padrão é claramente um fator da cooperação útil alcançada:
  • RS-232 ( Ruim , não especificado o suficiente, até mesmo qual pino transmite e qual pino recebe é opcional, sheesh. Você pode obedecer, mas ainda assim não conseguir nada. Chance de interoperabilidade bem-sucedida: muito baixa até que o IBM PC fizesse um padrão útil de fato .)
  • IEEE 754-1985 Floating Point ( Ruim , overreach: nem um único supercomputador ou estação de trabalho científica ou microprocessador RISC o adotou, embora eventualmente, após 20 anos, tenhamos sido capazes de implementá-lo bem em HW. Pelo menos o mundo acabou crescendo.)
  • C89, C99, PCI, USB, Java ( bom , seja padrão ou especificação, eles conseguiram motivar a conformidade estrita de quase todos, e essa conformidade resultou em uma interoperação bem-sucedida).
• não foi selecionado como o banco de dados mais importante do mundo . Embora isso seja mais um ponto de dados do que um motivo, o fato de o Google Bigtable não ser SQL e não relacional é uma espécie de anti-realização para SQL.

Não desgosto de SQL, mas também não quero ter que escrevê-lo como parte do que estou desenvolvendo. O DAL não se trata de velocidade para o mercado - na verdade, nunca pensei que haveria uma implementação de DAL que seria mais rápida do que consultas diretas do código. Mas o objetivo do DAL é abstrair . A abstração tem um custo, e aqui é que levará mais tempo para ser implementada.

Os benefícios são enormes, no entanto. Escrever testes nativos em torno do código, usando classes expressivas, conjuntos de dados fortemente tipados, etc. Usamos um "DAL" de tipos, que é uma implementação DDD pura usando Genéricos em C #. Portanto, temos repositórios genéricos, implementações de unidade de trabalho (transações baseadas em código) e separação lógica. Podemos fazer coisas como simular nossos conjuntos de dados com pouco esforço e realmente desenvolver antes das implementações de banco de dados. Havia um custo inicial na construção de tal estrutura, mas é muito bom que lógica de negócios seja a estrela do show novamente. Consumimos dados como um recurso agora e lidamos com eles na linguagem que estamos usando nativamente no código. Um benefício adicional dessa abordagem é a separação clara que ela fornece. Não vejo mais uma consulta de banco de dados em uma página da web, por exemplo. Sim, essa página precisa de dados. Sim, o banco de dados está envolvido. Mas agora, não importa de onde estou puxando os dados, há um (e apenas um) lugar para entrar no código e encontrá-lo. Talvez não seja um grande problema em projetos menores, mas quando você tem centenas de páginas em um site ou dezenas de janelas em um aplicativo de desktop, você realmente pode apreciá-lo.

Como desenvolvedor, fui contratado para implementar os requisitos do negócio usando minhas habilidades lógicas e analíticas - e nossa implementação de framework permite que eu seja mais produtivo agora. Como gerente, prefiro que meus desenvolvedores usem suas habilidades lógicas e analíticas para resolver problemas do que escrever SQL. O fato de podermos construir um aplicativo inteiro que usa o banco de dados sem ter o banco de dados até mais perto do final do ciclo de desenvolvimento é uma coisa bonita. Não é uma crítica aos profissionais de banco de dados. Às vezes, a implementação de um banco de dados é mais complexa do que a solução. SQL (e em nosso caso, Views e Stored Procs, especificamente) são um ponto de abstração onde o código pode consumir dados como um serviço. Em lojas onde há uma separação definitiva entre as equipes de dados e de desenvolvimento, isso ajuda a eliminar a espera pela implementação e mudanças do banco de dados em um padrão de espera. Os desenvolvedores podem se concentrar no domínio do problema sem passar o mouse sobre um DBA e o DBA pode se concentrar na implementação correta sem que um desenvolvedor precise dissoagora .

Muitos posts aqui parecem argumentar que o SQL é ruim porque não tem recursos de "otimização de código" e que você não tem controle sobre os planos de execução.

Os motores SQL são bons em criar um plano de execução para uma instrução escrita, voltada para os dados , o conteúdo real . Se você olhar além do lado da programação, verá que os dados são mais do que bytes entre as camadas do aplicativo.