O SQL é importante se conheço bem os frameworks ORM? [fechadas]

Isso é difícil de explicar para muitos programadores, porque se você só conhece SQL básico então realmente não lhe dá muita vantagem sobre a muleta de um ORM. Os conceitos SQL mais avançados, no entanto, são uma parte crucial da diferença entre os aplicativos que apenas trabalham contra aplicativos de alta qualidade (em particular, rápidos e confiáveis).

Estou assumindo que alguém projeta os bancos de dados para você, porque fazer isso sem conhecer qualquer SQL está além do limite. Mas mesmo que você esteja apenas se desenvolvendo contra eles, aqui está apenas uma lista parcial de todas as coisas que os ORMs ainda tendem a fazer mal ou de maneira alguma:

• Consultas recursivas e / ou de hierarquia
• Parâmetros opcionais (especialmente traduzindo-os em predicados de intervalo)
• Tipos de dados definidos pelo usuário
• Tipos específicos de plataforma (SQL hierarchyid e TVPs, matrizes Oracle e tabelas aninhadas, etc.)
• Inserções em lotes / atualizações / upserts / exclusões
• Dicas de índice
• Bloquear dicas (especialmente bloqueios de atualização e leituras sujas)
• Tratamento de erros
• Associações externas - seus conjuntos de resultados são mal mapeados para o modelo OOP, muitos ORMs têm sua própria linguagem de consulta, mas é semelhante a conhecer o próprio SQL;
• Modularização por meio de procedimento armazenado e UDFs, especialmente UDFs sequenciais e consultas CROSS APPLY
• Uso de OUTPUT / RETURNING para testar dados em várias tabelas
• Consultas de paginação eficientes
• Consultas baseadas em funções de janelas (rownum, rank, partitions)

A lista continua - muitas dessas coisas que um DBA iniciante nunca teve que fazer, e um desenvolvedor novato nunca ouviu falar - mas elas são muito importantes em aplicativos de larga escala.

ORMs são ótimos para acelerar o verdadeiro código SQL chato - isto é, todo o CRUD e mapeamento repetitivos e outros códigos de encanamento, então não há absolutamente nenhuma vergonha em usá-los e não ouça qualquer um que diga que eles são maus. Mas você definitivamente ainda precisa aprender e sim, mesmo mestre SQL, e estar preparado para cair em comandos / consultas de banco de dados brutos quando o ORM não está puxando seu peso.

Absolutamente! O SQL ainda é a língua franca dos bancos de dados e, embora você possa fazer muito com ORMs, é necessário entender o SQL para entender as decisões que os ORMs tomam e o SQL que eles geram. Além disso, ainda há muitas coisas que você precisa fazer com procedimentos personalizados de sql e armazenados. Desculpe, sem almoço grátis.

Sim, você ainda precisa conhecer o SQL. Os ORMs são uma abstração muito fraca e não fornecem acesso a todo o potencial do SQL. Para aplicativos toy , você pode estar satisfeito com conhecimento limitado de SQL. Para aplicativos corporativos, você terá que entender o banco de dados para obter um desempenho decente do ORM. Também há muitas tarefas que são muito mais facilmente executadas com o SQL do que com uma linguagem de aplicativo. Eu vi programadores Java passarem dias escrevendo código para fazer algo que poderia ter sido codificado em SQL em uma hora. O conhecimento de SQL é muito valioso para quem escreve aplicativos que usam um banco de dados relacional.

A habilidade SQL é uma habilidade indispensável na TI hoje. LINQ é uma tecnologia Microsoft Only. Os usos do SQL vão além do desenvolvimento de aplicativos da Web e do cliente / servidor. Você não pode modelar bancos de dados e fazer ETL se não for bom com SQL. Talvez você não precise dominar os dialetos SQL usados no ORACLE e no SQL Server para seus produtos Data Warehous, mas você deve saber o SQL padrão. Noções básicas de SQL são simples, existem toneladas de material para você começar.

Se você estiver interagindo com um banco de dados SQL, você deve entender o SQL que o ORM está gerando. Você deve entender os conceitos inerentes aos bancos de dados SQL e deve entender o que seu ORM não pode fazer por você. ORMs tornam a vida mais fácil (e sim, acho que trabalhar sem qualificá-lo como dinossauro em muitos casos), mas são ferramentas (para abstrair as coisas que você sabe), não muletas (para evitar que você aprenda).

Se você se recusar a aprender SQL, você não terá nenhum problema em tocar nos bancos de dados SQL, com ou sem um ORM, e deverá encontrar outro tipo de trabalho.

Admito que sou um fã obstinado do ORM e venho pregando os benefícios do ORM há anos e tenho muito a dizer sobre por que o ORM supera o SQL.

MAS ...

Eu tenho que admitir que o SQL é totalmente e totalmente necessário no mundo real e todo desenvolvedor deve ter uma boa compreensão do SQL.

Os processos SQL são mais rápidos que o ORM em quase todos os casos. Mesmo que você possa otimizar a saída ORM na maioria dos casos, ela também fica em segundo lugar no SQL procs.

Ocasionalmente, você precisa de um SQL pesado para obter o resultado desejado, e essas consultas de monstros são mais fáceis e rápidas de criar em procs SQL.

Apenas meus dois bits.

Chegará um momento em que você terá que otimizar algo complexo que o ORM está criando. Nesse ponto, você geralmente tem uma consulta extremamente complexa para quebrar. Se você nunca aprendeu o básico, como você pode esperar começar a aprender SQL com as coisas avançadas? Você não vai entender o suficiente para começar. ORMs nas mãos de uma pessoa que entende SQL - uma boa ferramenta. ORMs nas mãos de alguém que não conhece SQL - desastre esperando para acontecer.

Uma das razões pelas quais o SQL é crítico para entender os bancos de dados é que os programadores de aplicativos não pensam naturalmente em termos de conjuntos de dados. Mas a única maneira pela qual os bancos de dados operam eficientemente é por conjuntos. Você precisa aprender a pensar em conjuntos antes mesmo de tentar usar um ORM.

Eu me vejo forçando manualmente as consultas em estruturas ORM com mais freqüência do que não. E enquanto a maioria tem sua própria linguagem de consulta, todas são inspiradas pelo sql, o código é transformado em sql e você precisa entender o que está errado lendo o sql quando (não se, quando) as coisas dão errado ou não funcionam bem. br> Portanto, mesmo que você não esteja escrevendo diretamente sql, entendendo além de um nível básico (embora você provavelmente não precise aprender coisas sobre como escrever procedimentos armazenados, gatilhos, etc., se tudo o que você vai fazer é acessar bancos de dados) você deve conhecer a linguagem o suficiente para entender o código gerado e ajustá-lo conforme necessário.

Antes de falar sobre a questão, uma pequena introdução primeiro; Eu amo ORMs. E eu odeio SQL. Eu amo os ORMs porque eles escondem a bagunça hostil do usuário que o SQL é, e fornecem uma maneira agradável e integrada de lidar com o banco de dados.

No entanto, tenho que admitir que o SQL tem muitos benefícios, sendo o maior deles a precisão. Eu posso praticamente argumentar sobre a complexidade de uma consulta SQL, sem conhecimento detalhado do esquema do banco de dados subjacente, apenas passando pela consulta. Portanto, quando uso o SQL, estou sempre alerta e sempre tenho uma intuição sobre a direção da complexidade de um componente.

Por outro lado, ao usar ORMs, fico tão impressionado com a facilidade da integração do banco de dados, que literalmente esqueço que existe um banco de dados. Isso me ferrou várias vezes. Muitas vezes, no passado, eu chamei métodos ORM aparentemente inocentes, que nos bastidores chamam junções massivas e assustadoras de bancos de dados, que destroem o desempenho.

É por isso que, para mim, a verdade está em algum lugar no meio. Eu adoro usar ORMs, e continuarei fazendo isso, mas preciso ser mais cuidadoso e sempre estudar as implicações (no nível SQL) de qualquer chamada de método ORM. Conhecer as implicações de uma camada de abstração é ouro puro nesse negócio e justificar o uso da abstração. Qualquer outra coisa, é como atirar no próprio pé.

Se tudo o que você precisa fazer é interagir com o banco de dados apenas com o aplicativo que está criando, provavelmente não precisará dele. Em algumas empresas menores ou equipes de desenvolvedores, talvez você precise fazer algum suporte. É muito mais fácil se conectar ao banco de dados de um cliente e executar algumas instruções sql para ver o que está acontecendo com seus dados.

Mesmo com um ORM bom e maduro, você inevitavelmente irá se deparar com situações em que emitir algum SQL ineficiente e tornar sua vida mais fácil se você conseguir aumentar o que está acontecendo no SQL gerado. Dito isto, se você é muito proficiente com o ORM e sabe como usar um profiler para seu DB de escolha, você pode facilmente "fingir até conseguir".

A resposta para todos esses tipos de perguntas ("preciso saber X?") é "aprender da primeira vez que você precisar, se precisar".

Nesse caso específico, por exemplo, o que você faz se perceber que houve um bug no seu programa que fez com que o campo PostCount de sua tabela de usuários às vezes fosse impreciso.

Você corrigiu o bug e agora precisa atualizar o PostCount para todos os usuários. Como você faz isso?

Se você escrever um pequeno script usando o ORM para fazer isso, estará sendo muito ineficiente; uma consulta SQL muito simples serve.

Como essas situações são bastante comuns, temo que você tenha caído na armadilha descrita acima!

Sim, você ainda precisa do SQL.

Não pule para a suposição de que algo "antigo" é de alguma forma indigno de consideração. As chamadas tecnologias "legadas" são aquelas que ainda estão por aí depois de passarem no teste do tempo. Nós não chamamos os computadores de Wang de "legado", eles falharam e sumiram.

Se você me perguntar, será que meu banco provavelmente está usando o COBOL em um mainframe ou IBM i? Absolutamente não. Estas são tecnologias sólidas, experimentadas e verdadeiras. Adivinhe, eles estão usando principalmente o DB2 SQL. Estou muito mais feliz confiando no meu dinheiro do que no software desenvolvido em uma linguagem moderna do mês.

Os dinossauros duraram muito mais tempo do que nós humanos. E se você ler o Jurasic Park (sim, livros são melhores que filmes), então eu pergunto: você realmente quer enfrentar um pacote de velociraptors hiper-inteligentes, ou um T-Rex obstinado que nunca desiste? Não seja mordido por subestimar os "dinossauros". ; -)

Além de jogos e pesquisas (principalmente estatísticos), com os quais não tenho experiência, parece que o acesso ao banco de dados e as operações são uma das poucas áreas em que decisões erradas levam a um impacto muito grande no desempenho. Acredito firmemente em abstrações de banco de dados mais poderosas no código, e acredito que o linq, que vincula as operações do banco de dados à linguagem de programação, fornece todas as ferramentas da linguagem (verificação de tipos, verificação de sintaxe, tudo o que você gosta sua linguagem de programação), enquanto ainda dá a você muito poder para fazer o que você quer, é absolutamente fantástico. Infelizmente, nem sempre funciona. Isso significa que, se a camada de abstração obtém suas otimizações erradas, você pode estar esperando por segundos, em vez de microssegundos, ou minutos, em vez de segundos, por seu resultado. Como esses são tempos muito visíveis, você precisa otimizá-los ou seu aplicativo não "funciona": o desempenho se torna o maior problema do seu aplicativo. Isso significa que você precisa se aproximar do metal e otimizar a mão.

Quando chegamos ao ponto em que manipular grandes conjuntos de dados leva, por exemplo, 3 ms ao fazer manualmente, e 100 ms quando você deixa a camada de abstração fazer isso por você, por todos os meios, deixe a camada de abstração lidar com você, porque você pode ser 30 vezes mais lento, mas você ainda é (provavelmente, para a maioria das aplicações) rápido o suficiente. A realidade da situação é que, quando você está procurando soluções otimizadas onde você tem um tempo de resposta de 200 ms, e quando a camada de abstração lida com isso, o algoritmo leva apenas 10 vezes a performance, você tem um 2 segundo atraso e, em seguida, você se importa muito, pois vai de não tão rápido, dolorosamente lento. Vendo que soluções de bancos de dados relacionais não escalam bem , eu Não pense que isso será resolvido em dois ou três anos. Isso significa que você ainda terá que chegar ao zero por algum tempo quando se trata de bancos de dados maiores, ou seu aplicativo será tão lento, não pode resistir aos concorrentes.