Mitos sobre Stored Procedures, uma análise

Quer ler o PDF deste post, baixe aqui.

Recentemente o Giggio escreveu um post intitulado “Mitos sobre Stored Procedures” e até me mandou um tweet dizendo “Alguma coisa a completar sobre o que escrevi?!”. Somente hoje consegui parar e fazer uma análise crítica do post e das respostas, então resolvi colocar tudo em forma de post.
Antes de continuar escrevendo, gostaria de ressaltar meu posicionamento sobre o assunto e exemplificar com o Entity Framework, que é o ORM que eu conheço um pouco. 

1. Sou a favor de frameworks ORMs. Isso mesmo, um SQLGeek falando isso! Gosto da idéia de abstrair a complexidade de bancos relacionais através de um modelo de entidades e permitir que o desenvolvedor possa utilizar o LINQ to Entities (por exemplo), que será traduzido para um T-SQL ou PL-SQL. 
2. Não acho que ORM é a solução para todos os problemas. Vejo ORMs principalmente para aquelas aplicações (ou parte delas) que fazem manipulações simples de entidades com pequenas massas de dados, CUD ou consultas com um ranking, agrupamentos e outras operações set-based simples. Isto é, para operações data intensive (ex.: fechamento de um processamento diário ou cálculo de premiação mensal) você não vai querer um tráfego gigantesco de dados entre o banco e sua aplicação, só para manter a regra de negócio em um só ponto. 
3. Programar regras de negócio em C# é mais fácil que em T-SQL. Senhores, T-SQL é uma linguagem restrita para escrita regras de negócio, prefiro 1000 vezes escrever minha lógica em C#. Exemplo bobo, faça um try/catch no T-SQL que acabe em um rethrow da exceção... Eu já tenho a minha proc_Rethrow, e você? 
1. T-SQL é muito poderoso e eficiente dentro de seu objetivo primário, manipulação de conjunto de dados.
4. Lixos T-SQL espalhados por aí. Essa é minha maior preocupação, se 70% dos desenvolvedores escrevem código C# ruim, 95% dos devs escrevem consultas T-SQL horríveis. E isso, desculpem o termo, FODE com o banco de dados e aplicação! Deixando de lado os problemas do EF V1 na geração de T-SQL, o EF 4.0 é bem mais eficiente e prefiro 1000 vezes a tradução do e-SQL do EF feito por uns indianos malucos (piadinha, ok?!) a deixar nossos desenvolvedores escreverem as consultas.
1. Sim, talvez seja preconceito. Certa vez estava em uma apresentação sobre ORMs uma pessoa disse: “eu não quero pagar esse overhead de X milisegundos de tradução do EF porque todas as minhas consultas são bem escritas”. Bom, eu erro, e a menos que você seja um programador T-SQL fodístico-mega-flawless como esse camarada, um ORM pode ajudar.

 Agora a análise dos pontos que o Giggio citou: 

1. Concordo em geral. Planos ficam guardados, tanto de consultas ad-hoc quanto de procedimentos e sim, existe statement level recompilation a partir do 2005. O SQL Server desde versões anteriores tenta fazer uma auto-parametrização das suas consultas ad-hoc, mas ele somente conseguirá fazer isso se a sua consulta possibilitar que um mesmo plano possa ser reutilizado de forma segura para TODOS os parâmetros possíveis. 
2. Não é um mito, SP estimula a reusabilidade no contexto do banco de dados. O que eu concordo é que existem outras maneiras, possivelmente mais eficientes de atingir esse objetivo.
3. Mesmo do item 2, não é um mito no contexto de banco de dados, mas posso aproveitar bem minha aplicação para isso.
4. Discordo. No SQL Server existe uma coisa chamada ownership chaining, que permite criar um cenário onde um usuário não tenha acesso direto a tabela (nada de selects ou CUDs na tabela) e através de uma procedure com mesmo “dono” o usuário com permissão de EXEC na proc possa chegar a tabela. É uma característica que nos permite um bom controle.
1. Não vou entrar em detalhes aqui das aplicações mal desenvolvidas. Quero me jogar da janela toda vez que alguém vai instalar um novo software e o camarada me pede: preciso de SA ou dbowner. Normalmente isso acontece porque a empresa que desenvolveu o software não utilizou o princípio de desenvolver com menor privilégio possível e não sabe (isso mesmo, é ignorância sobre seu próprio software) quais são as reais permissões necessárias. AAARRRGGGHHH.
5. É uma verdade, só acho que esse é um argumento ridículo em termos de otimização. Se você está falando que seu ambiente está tão otimizado que você está considerando esse ganho ínfimo, por favor, me chame para conhecer seu ambiente que faço uma revisão grátis da saúde do SQL Server (agora, se eu encontrar um problema maior, cobro em dobro as horas, ok?). 

Sinceramente, eu acho que a discussão tem que sair um pouco do plano do mito (isso é bom para incentivar uma guerrilha :-)), mas sim no seguinte: eu posso fazer algumas dessas coisas de forma mais eficiente ou, tão-eficiente quanto, usando essa outra abordagem: ORM.

Alguns comentários sobre os comentários... 

• ETL – Esqueçam ETL x ORM, não trabalham juntos. Reporting não é ETL. Realmente não entendi essa viagem sobre ETL. Seu ORM ou SP garantem que o dado JÁ está consistente com a regra de negócio no banco de dados, dados consistentes é isso que eu preciso, agora me deixem em paz que eu vou trabalhar diretamente com os dados, seja para uma carga de DW ou outra coisa, ponto final.
• E DUVIDO que alguém vai ficar no SSIS customizando um script component como source só para reutilizar uma DLL com um EF lá dentro (exmeplo). Não me parece muito esperto não...
• Gostei das respostas do Ronaldo Tolentino. A realidade hoje é outra e temos muito legado, então regras dentro de SPs permitem que diferentes sistemas estejam em acordo e eu possa mudar a regra em somente um lugar.
• Sei que posso usar uma DLL, refazer a distribuição entre aplicações diferentes, carregá-la dinamicamente no AppDomain, MAS, caímos na questão da manutenção. Tenho expertise para tal? Como vou controlar as diferentes versões dos diferentes sistemas? A troca da DLL trará um efeito colateral?
• Discordo do Giggio quando ele diz que existem maneiras mais simples, existem sim outras maneiras, mas a facilidade é um termo subjetivo de acordo com nossa experiência.
• A frase “No banco de dados, a unica coisa que vc otimiza é as procedures, agora na aplicação vc tem inumeras arquiteturas q lhe possibilitam isso”.
• Ah Danimar, Danimar, se fosse só isso eu estaria desempregado... 

Conclusão: DEPENDE!

É idiota, mas verdade. A diferença está quando você responde “depende” sabendo analisar criticamente seu cenário ou quando você responde depende e começa a falar bobagens. Vocês podem ficar brigando dias e dias, mas o que serve para um pode ser horrível para o outro.  

Não sou purista e hoje trabalho com uma abordagem híbrida. Utilize seu ORM para aquele “front-end básico de BD” (90% da aplicação que o desenvolvedor júnior consegue programar) e quando houver relatórios em tempo real ou operações complexas que sejam data intensive, coloque em SPs e apresente isso como uma função na entidade mais adequada. Sem dor. 
No mais gostei do post e das discussões, bom para aquecer um início de dia...

 

[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/