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

51

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?

Qualquer um
fonte
14
Eu me sinto velho. O SQL foi abstraído o suficiente para que agora você possa fazer essa pergunta seriamente.
Mark
11
@ Mark: Talvez você possa fazer seriamente a pergunta, mas a resposta ainda é a mesma.
Adam Robinson
30
O conhecimento da aritmética ainda é importante se eu puder usar uma calculadora?
Steven A. Lowe
4
NHibernate sem conhecimento de SQL Profiler e como agradar sua barriga para uso JOINs, é uma jihad desempenho à espera de acontecer para o seu servidor de banco de dados
Chris S
2
Você precisa conhecer HTML se pode usar o Dreamweaver?
Tulains Córdova 6/08/13

Respostas:

63

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.

Aaronaught
fonte
Eu concordo com a maioria dos seus pontos, mas com relação às junções externas: sim, elas são mal mapeadas no OOP, mas acho que o equivalente ao OOP (por exemplo, GroupJoinno LINQ) é muito melhor.
svick
@sick: Ele tem seus usos, mas não é a mesma coisa. Tente emular uma junção externa completa com GroupJoin.
Aaronaught
Sim, não é a mesma coisa. E eu acho que o que você precisa na maioria das vezes é realmente GroupJoin. É que as pessoas que estão acostumadas ao SQL pensam imediatamente em junções externas nesses casos e perguntam como traduzir isso para o LINQ. Essa não é a abordagem correta. Você não deve tentar converter seu SQL em LINQ, deve traduzir o que precisa diretamente.
svick
@ Rick: Obrigado pela dica. Odeio a classificação puxar, mas depois de um hiato de um ano eu ainda sou um dos maiores contribuidores para ambos SQL e Linq no Stack Overflow, por isso estou bastante certeza eu entendo a diferença de abordagem. Junções completas são raras, mas às vezes elas são realmente o que você precisa e simplesmente não há analógico no Linq. É bastante confuso e ineficiente obter o mesmo conjunto de resultados , independentemente de como está estruturado .
Aaronaught
Parece que realmente concordamos. Na maioria dos casos, você realmente não deseja junção externa. Mas quando você faz isso, é difícil traduzi-lo para o LINQ.
svick
90

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.

Otávio Décio
fonte
6
De fato. Você precisa saber, por exemplo, o impacto de diferentes instruções de junção e como isso afeta o desempenho.
Quíron
15
+1 Sem almoço grátis! O que há com todas as perguntas basicamente perguntando se a ignorância é boa?
benzado 14/08
7
@ benzado: Não que eu ache que seja necessário para o SQL, mas você precisa escolher a ignorância de algumas coisas; existem muitas tecnologias (mesmo as boas!) para realmente conhecer todas elas. Então, acho que é bom perguntar "X é desnecessário se eu conheço Y muito bem ou se estou fazendo Z?"
Craig Walker
2
@ Craig Eu concordo que há muito para aprender, mas um programador realmente deve ter um conhecimento básico dos níveis abaixo de onde está trabalhando.
23911 benzado
2
Os bancos de dados do @Craig Walker são um conhecimento crítico para a maioria dos aplicativos de negócios que não é bom ter.
HLGEM 15/08/11
25

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.

Kevin Cline
fonte
14

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.

NoChance
fonte
11
Qualquer pessoa que saiba como o LINQ funciona poderá aprender SQL básico em um dia. Este é um argumento terrível para aprender SQL.
Boris Yankov
6

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.

Marnen Laibow-Koser
fonte
Embora eu concorde que conhecer SQL é muito útil - basicamente obrigatório - eu discordo de seus motivos. Com esse raciocínio, você precisa conhecer o ASM e a arquitetura da CPU antes de escrever qualquer programa, porque as linguagens de alto nível tornam as coisas mais fáceis, mas são ferramentas (para abstrair), portanto, se você se recusar a aprender as instruções e a arquitetura do processador, não precisará usar um computador <--- Não faz sentido. A verdadeira razão pela qual você precisa é que as ferramentas ORM ainda estão engatinhando; Eu não ficaria surpreso se 5-10 anos de conhecimento agora SQL deixa de ser necessário
Thomas Bonini
Linguagens de alto nível são construídas de forma a impedir que você precise conhecer a arquitetura subjacente, é verdade. Isso é possível porque o domínio é proporcional à arquitetura subjacente. ORMs, no entanto, são uma questão diferente. Sou um grande fã de ORMs, mas acho que nunca chegará um dia em que você possa usá-lo sem conhecer o SQL (ou o que o DB subjacente usar). Os modelos objeto e relacional são fundamentalmente incomensuráveis, e acho que sempre haverá conceitos que não se traduzem de um para o outro. Além disso, eu estou falando sobre ORMs de hoje, não futuro
Marnen Laibow-Koser
3
+1: "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."
Vector
2
Eu votaria isso um milhão de vezes, se pudesse. Existem muitas pessoas que não têm negócios com os bancos de dados SQl devido à sua incompetência geral e à falta de compreensão do que estão fazendo. Eles arriscam onde quer que estejam criando pesadelos de desempenho e redigindo relatórios (dos quais são tomadas as decisões reais de negócios) que têm resultados desgastantes sem nunca perceber, pois ignoram deliberadamente o SQl como se fosse algum tipo de distintivo de honra descartar o banco de dados isso é crítico para suas aplicações.
HLGEM 15/08/11
11
+1 em "ferramentas (para abstrair coisas que você sabe), não em muletas".
sholsinger
4

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.

SetiSeeker
fonte
4

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.

HLGEM
fonte
3

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.

jwenting
fonte
3

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é.

Charalambos Paschalides
fonte
3
Também acho que às vezes (mesmo com SQL regular) as pessoas esquecem que só porque ele retornou um conjunto de dados não significava que era o conjunto correto. Eu acho que isso fica mais fácil de esquecer com um ORM quando você assume que ele fez a coisa correta, pois você realmente não entende o que ele fez de qualquer maneira.
HLGEM 15/08/11
Não concordo que o ORM seja menos complexo que o SQL. Com o SQL, você pode recuperar dados sem programação. O SQL não é uma linguagem de programação, mas uma declarativa; portanto, não há um tempo para as estruturas if-then.
Tulains Córdova
11
Uma linguagem de programação declarativa, ainda é uma linguagem de programação. SQL é uma linguagem de programação para fins especiais e, sim, é declarativa para a maior parte. Quanto à carne do seu comentário, eu não entendo. O SQL, embora não seja uma linguagem de programação de uso geral, ainda é uma linguagem. Você ainda precisa conhecer a sintaxe, suas limitações e defeitos.
Charalambos Paschalides
2

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.

JeffO
fonte
Quem precisa interagir SOMENTE com o banco de dados através do aplicativo que está construindo?
Tulains Córdova 06/08/13
2

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".


fonte
1

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!

Thomas Bonini
fonte
2
Concordo: se você não conhece SQL, muitas vezes escreve dezenas de linhas de código para fazer o que poderia ter feito com uma única consulta SQL.
benzado 14/08
2
re "aprenda na primeira vez que precisar": ro-che.info/ccc/11.html
MatrixFrog
1

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". ;-)

WarrenT
fonte
0

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.

Martijn
fonte