Ainda é necessário escrever SQL?

Com tantas ferramentas ORM para a maioria das linguagens modernas, ainda existe um caso de uso para escrever e executar SQL em um programa, em uma linguagem / ambiente que as suporte? Se sim, por quê?

Para maior clareza: não estou perguntando se os programadores precisam conhecer SQL ou se devo ter uma ferramenta SQL na área de trabalho. Estou perguntando especificamente por que eu posso tê-lo em código (ou configuração, ou o que for) em oposição a um ORM.

• Você se sente mais confortável escrevendo SQL para consultar dados do que escrevendo código processual.
• Seu ORM, embora bonito de se ver, gera SQL horrivelmente lento em alguma área crítica.
• Você precisa aproveitar a funcionalidade exposta pelo seu RDBMS que não é / não pode ser disponibilizada através do seu ORM.
• Toda vez que você digita SELECT * FROM..., Deus mata um gatinho. E você odeia gatinhos.
• Você não está usando um ORM, OOP ou um idioma moderno.

Escrevendo SQL complexo

ORM são ótimos para coisas básicas. No entanto, para situações complexas, você precisará escrever SQL.

Portanto, em suma, certamente existe uma necessidade de SQL e sempre permanecerá assim.

• Visualizações
• Gatilhos
• Restrições
• Pacotes (SSIS, DTS, etc)
• Sempre que você precisar controlar o fluxo de execução com precisão

O ORM não ajuda a criar, ajustar ou automatizar o banco de dados. Ele apenas fornece uma maneira alternativa de interagir com o banco de dados depois de fazer tudo isso.

Certo:

• Geralmente o ORM encapsula muito, mas no final você deve saber o que acontece nos bastidores. Isso é crucial para desempenho e escalabilidade. Embora dentro do aplicativo eu não escreva muito SQL, mas sei aproximadamente como é o SQL ou o DDL.
• O Direct SQL geralmente é bom para escrever consultas somente leitura. É muito mais fácil formulá-lo na linguagem de consulta ORM e você também pode limitar o conjunto de resultados (por exemplo, 'selecionar id de .....').
• O ORM não deve mantê-lo longe do SQL. Eu uso muito o SQL para consultas ad-hoc diretamente no cliente DB (como mysql-client). Dá a você uma interface uniforme muito agradável e funcionalidades de agrupamento.

Os ORMs existem devido à incompatibilidade de impedância entre nossas implementações comuns de banco de dados relacional e nossos recursos de linguagem OO. Eles são apenas uma ponte, mas a maioria das pessoas trata o SQL como o queijo Limburger na geladeira.

Se você puder justificadamente dizer que sempre usará seu ORM ou outra camada de acesso a dados abstraídos em vez de tratar procedimentos / visualizações armazenados / SQL como uma interface de primeira classe, provavelmente será melhor sem tocar em SQL.

Na prática, nunca vi um projeto ORM puro que não exigisse pelo menos SQL para consultar o banco de dados para validação final.

ORMs são uma ferramenta na caixa de ferramentas dos programadores. Eles têm seus próprios problemas. Alguns exemplos são:

• Não é possível controlar o sql
• Sofre do problema n + 1

Se você souber o que está fazendo, poderá usar efetivamente um ORM para substituir grande parte do seu código de tipo CRUD. Porém, eles não são tão eficazes para coisas complexas, são difíceis de ajustar (você sabe que o desempenho é uma das partes críticas do design do banco de dados, não emula objetos) e é absolutamente horrível e perigoso nas mãos de alguém que não entendem ou escrevem SQL eles mesmos.

Também quero ressaltar que relatórios complexos não são fáceis de serem efetivamente executados com um ORM. Além disso, se você não aprender o SQL simples nas coisas fáceis, como chegará ao ponto em que pode escrever SQL complexo para relatórios? Nunca trabalhei em um aplicativo que não tivesse necessidades de relatórios e, muitas vezes, bastante complicadas.

Os ORMs também não são úteis para processos de BI ou ETL, na maior parte. Também não são úteis para consultas de administrador de banco de dados ou para encontrar informações nas tabelas de auditoria e desfazer um conjunto específico de alterações no banco de dados. Ainda existem muitas coisas que são feitas com mais eficácia com SQL. O aplicativo que consulta o banco de dados é uma pequena parte do que precisa ser consultado em um ambiente corporativo.

Também vejo muitas perguntas sobre como fazer algo usando um ORM que o pôster já sabe fazer no SQL. É bom aprender coisas novas, mas quando elas estão causando tempo e esforço extras sem ganho real em relação ao método original (e muitas vezes uma perda real de desempenho), por que você as está usando de outra maneira que elas não estão na moda agora?

Às vezes, um cliente deseja apenas uma consulta rápida e fácil para retornar dados de um relatório, exportação, datadump, etc, e deseja aguardar o desenvolvimento de um programa inteiro.

Além disso, um bom programador de SQL sempre pode escrever SQL mais rápido e eficaz do que qualquer ORM que eu tenha usado. Além disso, descobri que muitas pessoas têm apenas o ponto ORM para procedimentos armazenados - realmente ignorando os benefícios do ORM porque os ORMs não são bons para processos complexos.

Além disso, ao usar um banco de dados como Oracle com uma linguagem de procedimentos muito rica e poderosa, você pode fazer muito sem precisar de um "programa". O PL / SQL no Oracle na mão direita é muito rápido e eficaz.

Se você deseja usar um banco de dados, sim. A maioria dos ORMs que tentei usar não eram suficientes ou não cobriam meu banco de dados. Além disso, como você vai solucionar problemas ou escrever consultas personalizadas que não são cobertas?

Ainda é necessário para escrever gatilhos e procedimentos armazenados. Os procedimentos armazenados podem ter caído em desuso no momento, mas ainda são muito úteis em algumas situações. O SQL também pode ser necessário para algumas junções de várias tabelas particularmente peludas.

Sim, você pode evitar escrever SQL. Mas você acabará escrevendo HQL (ou Linq ou DQL ...)!

Sério, sou um grande fã de ORMs e acho que é possível evitar o uso de SQL puro na maioria das vezes. Mas devemos lembrar que um ORM é apenas uma grande abstração e todas as grandes abstrações vazam ...

(Mas sobre o problema do N + 1: isso está relacionado ao carregamento lento, e a maioria das ferramentas ORM tem alguma maneira de solicitar carregamento antecipado, evitando assim esse problema em particular.)

O ORM apenas o levará a algum ponto. Mas há casos em que você precisa executar uma consulta realmente complicada, com junções, subconsultas, uniões, menos, funções analíticas complicadas etc. É aí que você precisa do SQL. Mas como você deve escrever consultas complicadas quando deixa todas as consultas simples para o ORM?

Mesmo que você não precise escrevê-lo em seu código, é muito útil poder usá-lo quando você tiver acesso ao terminal para um servidor de banco de dados.

Além disso, mais do que faz a programação de um desafio é trabalhar dentro das restrições que os conjuntos de vida US- frequentemente nós estão trabalhando com código antigo, ou versões antigas de bancos de dados e não têm a oportunidade de instalar a biblioteca mais recente ORM por qualquer linguagem que são trabalhando com. Nessa situação, você precisará de qualquer ferramenta à sua disposição.

No restante do tempo, você pode não precisar do SQL para seu material CRUD, mas há muito mais no SQL do que simples consultas SELECT, INSERT, UPDATE e JOIN básicas. Você pode fazer coisas muito inteligentes e, embora não as use com frequência, é útil saber o que são.

Cada vez mais, acho que nos encontraremos em um mundo pós-SQL; no entanto, a maioria dos serviços em nuvem usa armazenamento de tabela não-sql e, para trabalhos simples do tipo CRUD, o poder total do SQL é desnecessário. Mas isso não significa que não haverá valor em entendê-lo.

Além disso, é claro, alguém precisa saber o suficiente para escrever um sistema ORM melhor se os atuais não forem muito bons. Ajudaria se soubessem SQL ...

Para criar aplicativos da Web em larga escala, é completamente desnecessário e pode tornar as coisas muito mais estressantes e perder tempo do que precisam. A razão para isso é que qualquer aplicativo em larga escala deve usar uma camada de persistência de memória (na RAM), que deve armazenar em cache as partes do banco de dados que são usadas com freqüência.

Se você precisar fazer coisas com dispositivos móveis, etc. que não tenham muita memória para trabalhar, onde o aplicativo que está sendo programado está sendo executado como um "cliente" ou aplicativo independente em um dispositivo móvel, tablet etc. coisas como usar SQL ainda são comuns e importantes porque a memória do dispositivo é tão pequena que você não pode armazenar muitas coisas na memória.

A complexidade e a quantidade de SQL que escrevo não são suficientes para tornar razoável a conexão de uma estrutura ORM.

(Eu escrevo SQL, talvez uma vez por mês, se)

Eu me deparei com muitos grandes corpos com DBAs que temem ativamente os desenvolvedores usando ferramentas ORM.

Eles são DBAs envolvidos no ajuste e no desempenho.

E sim, as ferramentas ORM podem ser gerenciadas para fazer coisas como essa, mas já vi lugares em que eles só aceitam um procedimento armazenado (Sql Server) e questionam você sobre o que você está fazendo nele.

Além disso, as ferramentas ORM podem ser mal usadas e produzir Sql tão ruim quanto escrever você mesmo.

One biggie - DDL e migrações de banco de dados. Às vezes, você precisa costurar manualmente essas coisas para atualizar as coisas sem quebrar os dados existentes.