O SQL é importante se eu conhecer bem as estruturas do ORM? [fechadas]

Não tenho nenhuma experiência séria em SQL e até odeio escrever SQL em vez de LINQ. Estou feliz o suficiente com ORMs.

Do ponto de vista dos empregadores e do setor, é importante conhecer o SQL? Eu tenho que dominar isso? As empresas que preferem SQL puro a estruturas ORM são um "dinossauro" no mundo da programação?

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

Suponho que outra pessoa projete os bancos de dados para você, porque fazer isso sem conhecer nenhum SQL está além dos limites. Mas, mesmo que você esteja desenvolvendo apenas contra eles, aqui está apenas uma lista parcial de todas as coisas que as ORMs ainda tendem a fazer mal ou nem fazem:

• Consultas recursivas e / ou hierárquicas
• Parâmetros opcionais (principalmente convertendo-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 lote / atualizações / upserts / exclusões
• Dicas de índice
• Dicas de bloqueio (especialmente bloqueios de atualização e leituras sujas)
• Tratamento de erros
• Junçõ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 isso é semelhante ao conhecimento do próprio SQL;
• Modularização por meio de procedimento armazenado e UDFs, especialmente UDFs inline e consultas CROSS APPLY
• Uso de OUTPUT / RETURNING para preparar dados em várias tabelas
• Consultas de paginação eficientes
• Consultas baseadas em funções de janelas (rownum, rank, partições)

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

Os ORMs são realmente ótimos para acelerar o código SQL realmente chato - ou seja, todo o CRUD e mapeamento repetitivo e outro código de encanamento, portanto, não há vergonha em usá-los e não ouça quem diz que é mau. Mas você definitivamente ainda precisa aprender e, sim, até dominar o SQL e estar preparado para entrar em comandos / consultas brutos do banco de dados quando o ORM não está exercendo seu peso.

Absolutamente! O SQL ainda é a língua franca dos bancos de dados e, embora você possa fazer muito com ORMs, precisa 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 sql personalizado e procedimentos armazenados. Desculpe, não há almoço grátis.

Sim, você ainda precisa conhecer o SQL. ORMs são uma abstração muito vazada e não fornecem acesso a todo o poder do SQL. Para aplicativos de brinquedo , você pode concordar com conhecimento limitado de SQL. Para aplicativos corporativos, você precisará entender o banco de dados para obter um desempenho decente do ORM. Além disso, existem muitas tarefas que são realizadas com muito mais facilidade com SQL do que com uma linguagem de aplicativo. Vi programadores Java passar 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.

Atualmente, a habilidade com SQL é essencial para a TI. LINQ é uma tecnologia Microsoft Only. Os usos do SQL vão além do desenvolvimento de aplicativos da Web e cliente / servidor. Você não pode modelar bancos de dados e fazer ETL se não for bom com SQL. Pode não ser necessário dominar os dialetos SQL usados ​​no ORACLE e no SQL Server para seus produtos Data Warehous, mas você deve conhecer o SQL padrão. Noções básicas sobre SQL são simples, há toneladas de material para você começar.

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

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

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

MAS...

Eu tenho que admitir que o SQL é total e totalmente necessário no mundo real e todo desenvolvedor deve ter um bom entendimento do SQL.

Os procs SQL são mais rápidos que o ORM em quase todos os casos. Mesmo que você possa otimizar a saída do ORM na maioria dos casos, ela também chega em um segundo próximo aos procs do SQL.

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 nos procs do SQL.

Apenas meus dois bits.

Chegará um momento em que você precisará 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 pode começar a aprender SQL com as coisas avançadas? Você não 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 o SQL - um desastre esperando para acontecer.

Uma das razões pelas quais o SQL é fundamental 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 de os bancos de dados operarem com eficiência é por conjuntos. Você precisa aprender a pensar em conjuntos antes mesmo de tentar usar um ORM.

Encontro-me forçando manualmente 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 no sql, o código se transforma em sql, e você precisa entender o que está acontecendo de errado lendo esse sql quando (não se, quando) as coisas dão errado ou apresentam um desempenho ruim.
Portanto, mesmo se você não estiver escrevendo sql diretamente, compreendendo-o 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ê fará é acessar bancos de dados). deve conhecer o idioma o suficiente para entender o código gerado e ajustá-lo conforme necessário.

Antes de falar sobre a questão, faça uma pequena introdução primeiro; Eu amo ORMs. E eu odeio SQL. Adoro ORMs porque eles ocultam a bagunça que o SQL não oferece aos usuários e fornecem uma boa maneira integrada de linguagem de lidar com o banco de dados.

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

Por outro lado, ao usar ORMs, fico tão impressionado com a facilidade de 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, chamei métodos ORM de aparência inocente, que nos bastidores chamam junções maciças e assustadoras de bancos de dados, que destroem o desempenho.

É por isso que, para mim, a verdade está em algum lugar no meio. Adoro usar ORMs e continuarei fazendo isso, mas tenho que ter mais cuidado 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 justifica o uso da abstração. Qualquer outra coisa, é como dar um tiro no próprio pé.

Se tudo o que você precisa fazer é interagir com o banco de dados apenas pelo aplicativo que você está criando, provavelmente você não precisa dele. Em algumas empresas menores ou equipes de desenvolvedores, talvez você precise fazer algum suporte. É muito mais fácil conectar-se 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 vai se deparar com situações em que ele emite algum SQL ineficiente e tornará sua vida muito mais fácil se você puder entender o que está acontecendo no SQL gerado. Dito isto, se você é muito proficiente com o ORM e sabe como usar um criador de perfil para o seu DB de sua escolha, você pode facilmente "fingir até conseguir".

A resposta para todos esses tipos de perguntas ("eu preciso conhecer o X?") É "aprendê-lo na primeira vez que precisar, se você precisar".

É importante, porém, não cair na armadilha de fazer as coisas com menos eficiência, porque você não está ciente ou não está disposto a aprender a maneira eficiente de fazê-las.

Nesse caso em particular, por exemplo, o que você faz se perceber que houve um erro no seu programa que fazia com que o PostCountcampo da tabela do usuário às vezes fosse impreciso.

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

Se você escrever um pequeno script usando 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 existem depois de terem resistido ao teste do tempo. Nós não chamamos os computadores Wang de "legados", eles falharam e se foram.

Se você me perguntar, isso me incomoda porque meu banco provavelmente está usando COBOL em um mainframe ou IBM i? Absolutley não. São tecnologias sólidas, testadas e verdadeiras. Adivinhe, eles estão usando principalmente o DB2 SQL. Estou muito mais feliz confiando no meu dinheiro lá do que no software desenvolvido em uma linguagem da moda do mês.

Os dinossauros duraram nesta terra por muito mais tempo do que nós, seres humanos, já existimos. E se você lê Jurasic Park (sim, livros são melhores que filmes), pergunto: você realmente quer enfrentar um bando de velociraptores hiper-inteligentes ou um T-Rex obstinado que nunca desiste? Não seja mordido subestimando os "dinossauros". ;-)

Além dos jogos e da pesquisa (principalmente estatística), com os quais não tenho experiência, parece que o acesso e as operações do banco de dados são uma das poucas áreas em que decisões erradas levam a um desempenho muito grande. 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 tipo, verificação de sintaxe, tudo o que você gosta sobre sua linguagem de programação), enquanto ainda lhe dá bastante poder para fazer o que você quer, é absolutamente fantástico. Infelizmente, ainda nem sempre funciona. Isso significa que, se a camada de abstração errar nas otimizações, você pode esperar segundos em vez de microssegundos ou minutos em vez de segundos pelo resultado. Como esses são tempos muito perceptí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 manualmente.

Quando chegamos ao ponto de manipular grandes conjuntos de dados, por exemplo, 3 ms ao fazer manualmente e 100 ms quando você permite que a camada de abstração faça isso por você, deixe a camada de abstração lidar com isso para você, porque você pode seja 30 vezes mais lento, mas você ainda (provavelmente, para a maioria dos aplicativos) é rápido o suficiente. A realidade da situação é, no entanto, que quando você está procurando soluções otimizadas à mão em que possui um tempo de resposta de 200 ms e quando a camada de abstração lida com você, o algoritmo leva apenas 10 vezes de desempenho, você tem um Atraso de 2 segundos, e então você se importa muito, pois passa de não tão rápido assim para dolorosamente lento. Vendo que as soluções de banco de dados relacional não escalam bem, Acho que isso não será resolvido em dois ou três anos. Isso significa que você ainda terá que se concentrar no metal por um bom tempo quando se trata de bancos de dados maiores, ou seu aplicativo será tão lento que não suportará os concorrentes.