Introdução
Quem nunca ouviu as seguintes frases: “Escrever SQL nos dias de hoje não é uma boa prática” ou “Tente não escrever SQL, usa os recursos do ORM”, ainda não trabalhou o suficiente.
O mercado de startups parece cada vez mais alérgico ao SQL, um dos recursos mais poderosos e antigos(1974!) no mundo dos bancos de dados.
O que as pessoas esquecem ou escolhem ignorar é a capacidade que um banco de dados tem e pode te oferecer para resolver problemas banais.
Mas a questão é, como e porque devemos perder o medo do SQL?
Escrever SQL é sim uma boa prática
Quando estamos envolvidos demais com os ORMs que utilizamos para fazer aplicações, tentamos cada vez mais resolver os problemas de acesso de dados utilizando os recursos do ORM que muitas vezes são muito bons e completos.
Porém, quando precisamos resolver consultas mais complexas, nós enfrentamos elas geralmente de duas formas diferentes:
- Realizando diversas buscas e processando a nível de aplicação
- Escrever uma String de SQL e executá-la com o ORM
Por mais vantajoso em termos de desempenho seja escrever a String da consulta dentro do ORM, muitas vezes preferimos processar essas consultas em tempo de execução utilizando os lindos recursos de nossas maravilhosas linguagens dinâmicas. Afinal, é deselegante escrever uma String com uma query SQL no meio do nosso Business Logic, né?
Esse pensamento é bastante comum, pouco eficiente e bastante errado. Quando assumimos fazer o item 1, perdemos os recursos de otimização de query que o banco nos fornece e damos lugar um código que é muito provavelmente ineficiente e tem pouca garantia de consistência. Quando assumimos o item 2, ganhamos o fator otimização porém perdemos no fator manutenibilidade.
Você pode alegar que não se pode ganhar todas né? Nesse caso, você pode sim ganhar todas.
Routines e Procedures
Funções internas do banco de dados são normalmente chamadas de Procedure ou Routine. Essas procedures se comportam como uma função em qualquer linguagem de programação, ou seja, podemos chama-las através de consultas, podemos utilizá-las em outras procedures e podemos também chama-las através do nosso ORM de preferência.
Se quiser ler mais sobre procedures nativas do PostgreSQL tem uma matéria bem legal dando uma palhinha do que ele pode fazer por você.
Minhas procedures
Você também pode definir procedures para trabalhar com suas tabelas e fazer operações nos seus dados. A forma de definir é bastante simples.
Para executar a procedure basta realizar uma consulta nela.
Podemos ver então que a declaração de uma procedure é bastante simples e flexível. Podemos ter funções com diversos retornos como tabelas, tipos nativos e tipos criados pelo usuário.
Existe também aqueles que gostam de trabalhar somente com SQL por já ter se estressado o suficiente com o ORM e tentou recriar o Devise utilizando procedures (Este é um artigo bastante interessante de alguém que cansou de ter problemas com ORMs).
Lógica de Dados VS Lógica de Negócios
Hoje em dia chamamos tudo que está rodando na nossa aplicação de lógica de negócios, porém, não é bem assim. É importante conhecer os limites e as diferenças do que é lógica de dados e o que é lógica de negócios.
Lógica de Dados
Lógico de dados é tudo aquilo que opera somente na camada dos dados (Duh), ou seja, é tudo aquilo que representa condições do nosso dado.
Exemplos:
- Criptografia de senhas
- Timestamps de tabela (createdAt, updatedAt)
- Softdelete (deletedAt)
- Consistências (Verificação de unicidade, chaves primárias, etc)
- Quando criar registro X, criar registro Y também
Lógica de Negócios
- Quando um usuário criar uma conta, disparar um Email de boas vindas
- Quando o usuário inserir um registro na tabela, notificar via SMS outro usuário
- Usuário x só pode acessar lugares x, y e z do sistema
Para fazer a lógica de negócios funcionar, devemos mapear a lógica em dados e trabalhar a lógica de dados para atender nossa lógica de negócios.
Em um mundo ideal existe uma completa separação entre essas lógicas mas no mundo real isso acaba se sobrepondo para agilizar o desenvolvimento.
Como escrever SQL da forma certa
Nos pegamos então em um mundo onde é inevitável escrever SQL. Em algum momento das nossas aplicações, vamos ter que colocar um SQL no meio do nosso código para resolver uma consulta complexa. Quando isso acontecer o que devemos fazer?
Meça
Consultas difíceis de escrever no ORM não é o único motivo para escrever SQL na sua aplicação. Muitas vezes o ORM que você está usando é lento para determinadas tarefas. Para resolver isso, fuja um pouco dele e trabalhe no nível do SQL.
Separe as lógicas
Saiba separar o seu SQL do código da aplicação. Crie uma procedure e faça uma chamada. Dessa forma você desacopla a lógica da consulta da aplicação e se um dia essa consulta operar de forma diferente basta atualizar a procedure.
Aproveite o melhor dos dois mundos
Meu objetivo não é convencer ninguém a parar de usar ORMs, mas saber medir e tomar deciões através de dados. ORMs não solucionam todos os problemas de acesso aos dados, além de adicionarem uma camada desnecessária de complexidade na aplicação.
Alguns exemplos:
Antes
Aplicaçao
Depois
SQL
Aplicaçao
