Os Sistemas Gerenciadores de Banco de dados atuais estão longe de ser somente administradores de dados, ou melhor, gerenciadores.
Como sabemos, eles tem mecanismos complexos de interpretação que lhes permitem implementar o recurso de Stored procedure(procedimentos armazenados) e com eles podemos aplicar lógica aos nossos dados além da que já existe com chaves primarias e estrangeiras e restrições de operações.
A pergunta que não quer calar é:
Isso é interessante para uma aplicação?
Tenho certeza de que já se perguntou isso, mas não vale a pena reorganizar a pergunta e faze-la novamente de uma maneira mais direta.
O que eu ganho e/ou perco ao utilizar stored procedures?
E a resposta pode gerar discussões homéricas, como as que já tive com várias pessoas da comunidade, com destaque para as que tive com os defensores mais ferrenhos de que não se deve usar esse recurso.
Começar por onde então… vamos pelo começo.
O primeiro argumento contra as stored procedures(a partir de agora SP, ok) é:
1- Esse tipo de recurso você vai ficar preso ao SGDB.
Natural pensar assim por que uma aplicação pode ter de mudar de SGDB no meio do caminho.
No caminho do sucesso, onde ela sai de um único usuário(admin) para N*10^24 usuarios/clientes com certeza os requisitos mudam. A requisição de performance muda. Tudo começa a ficar cada vez mais exigente. Mais banda, mais tps, mais e mais de cada recurso utilizado na aplicação.
Mas basear-nos nesse raciocínio nos levaria, no final das contas, a usar como modo de persistencia os arquivos textos e eles também impõem algum tipo de restrição, então, não podemos exagerar nesse pensamento.
Nós escolhemos um SGDB por algumas caracteristicas que fazem ele diferente dos outros. Por isso temos que fazer uma escolha. E se a escolha for consciente e calculada, o SGDB irá prover os recursos necessários por um bom tempo através de tunnings.
O segundo argumento contra SP’s é:
2- especialização do profissional.
Para que o software tenha boas SP’s é necessário que exista alguém no time que saiba escreve-las, que entenda a engine do SGDB, que conheça de planos de execução e se mantenha antenado as novidades desse tipo de recurso, ou seja, tudo aquilo que os profissionais de PHP(e de outras linguagens) já fazem diariamente com relação a sua linguagem de programação. É dobrar o trabalho, alguns diriam.
E por último, para me ater a somente três dos motivos clássicos que as pessoas me apresentam quando entro em uma discussão desse tipo:
3- A lógica da aplicação terá que ser mantida em dois lugares diferentes.
O analista terá de lidar com requisitos implementados em locais diferentes. A equipe de teste terá de lidar com testes em componentes diferentes e o arquiteto, se defensor desse tipo de abordagem, terá que se desdobrar para conseguir incluir nos softwares a execução dessas SP’s.
Revendo, então, aqui vão os três dos motivos que já ouvi para não utilizar SP’s em uma aplicação:
- Ficar preso a um SGDB.
- Necessidade de um profissional treinado em desenvolvimento de SP’s na equipe.
- Lógica de aplicação “espalhada” em vários lugares.
Esses três motivos na maioria das vezes impedem que o software se beneficie das SP’s no que ela foi criada para fazer.
Veja, manipular dados pode ter dois objetivos, a saber, manipular os dados para manter integridade, automatizar processos de normalização e outras tarefas que não afetam como os dados são recuperados ou gravados pelo usuario/desenvolvedor e o outro objeto é influenciar exatamente a maneira como o usuario/desenvolvedor manipula essas informacoes(mais conhecido como regras de negocio).
O medo de todos os desenvolvedores esta na segunda opção.
Stored procedures são recursos de programação como outro qualquer. Eles simplesmente não são built in da sua linguagem de programação predileta, mas TAMBÉM são uma maneira inteligente de lidar com os dados, assim como você instala uma extensão especializada em lidar com o dado complexo chamado e-mail, ou para atender requisições remotas(RPC) usando SOAP.
Para exemplificar, vou falar de PostgreSQL, de longe meu SGDB preferido e isso se dá muito devido as SP’s, que podem ser escritas em php, shell, tcl, java, pgsql, sql e tantas outras.
“Você pode levar seu conhecimento para dentro do SGDB”
No caso de SP’s em php no postgreSQL, de uma olhada aqui (https://public.commandprompt.com/documents/5) e veja até onde você pode ir com o conhecimento a equipe tem, mas para quem não quiser ir até lá, aqui tem um exemplo simples:
Ok, agora você tem a informação de que pode escrever SP’s em PHP no PostgreSQL, mas ainda sobra a dúvida de por que Escrever código no SGDB. A principal razão é: “Centralizar um algorítmo que sera utilizado por um sistema com N clientes(interfaces).” Quantas vezes você já presenciou um mesmo sistema com interface iPhone, iPad, iN, Android, Web, Desktop e vai saber que outro tipo de cliente pode ser criado para a mesma aplicação dependendo dos desejos de dominação mundial do produto? Quando isso acontece o time de desenvolvedores, sabiamente, antes de criar o projeto pensa em uma API e dessa forma conseguia reduzir o trabalho nessas aplicações de linguagens diferentes compartilhando algoritmos centralizados. Esse é o mesmo raciocínio por trás das Stored Procedures que trabalham com regras de negócio. A única diferença é que você encapsula o código dentro do banco de dados e isso fica transparente, até mesmo caso você não tenha tido tempo para desenvolver uma API. Ainda não esta convencido de que usar SP’s é uma boa ideia? Vou dar outro motivo:”Observers”. Você pode atrelar as SP’s a eventos do banco de dados, normalmente executando alguma tarefa quando os dados sofrem alteração(Insert, delete, update) e pode escrever sp’s para responder exclusivamente a selects, te entregando informações(e não dados – uma grande diferença). E por fim, para aqueles que insistirem em dizer que isso mudará a forma como o desenvolvedor trabalha, pois ele farão requisições ao banco de dados diferentes daquelas com que esta acostumado aqui vai um projeto bem simples que pensa nisso. Novamente para PostgreSQL, ao pensar nesse problema, acabei por criar um projeto chamado pl2method (http://ianntech.com.br/2008/10/30/pl2methods/) que permite continuar programando PHP usando as SP’s como se fossem métodos comuns de uma classe PHP. O desenvolvedor pode criar um facade sobre isso e dar ao sistema maior transparencia e segurança caso resolva trocar detalhes da SP, um uso simples esta descrito no artigo, porém, vou repeti-lo aqui:
No exemplo acima é criada uma classa p que acessa o Schema Testes de uma banco de dados dbdemo e requisita uma stored procedure chamada Teste.
O pl2method permite criticar os parametros passados, verificando tipagem, por exemplo e retorna para a requisição as informações seguindo o sistema da PDO.
É isso pessoal, espero que gostem.
Um grande abraço a todos.
Ivo Nascimento 
Store Procedures são interessantes em diversas situações, mas na minha opinião, com os excelentes ORMs que temos hoje, as SPs se tornaram algo desnecessario na maioria dos cenarios.
Mas mesmo assim seu artigo esta otimo.
Ps.: num rola instalar o disqus pros comentários? 🙂
Oi Diego,
ORM e Stored procedures não são mutuamente exclusivos.
Uma tecnologia pode apoiar a outra.
E sim, os ORM são hoje uma maneira mais que interessante para lidar com os dados, mas stored procedures também continuam importantes. Eu realmente discordo do termo “desnecessário”.
Nunca pensei em colocar frente a frente esses dois assuntos, como você colocou.. talvez seja uma boa análise a ser feita no futuro.
Quanto ao disqus… valeu pelo toque, não conhecia e já instalei para ver como se comporta. Ao menos a proposta é mto boa.
[]’s
Então, concordo que não são mutualmente exclusivas. Mas por exemplo, uma SP que retorna todos os usuarios, na tabela tb_user, junto com seu endereço, na tabela tb_address, é desnecessaria, porque o mapeamento do ORM facilita recuperar essa informação, ao contrario do SQL puro aonde teriamos que fazer JOIN manual.
Porem, o que eu considero o uso adequado de SP é pra adicionar funções que o banco de dados não possui nativamente, como por exemplo, selecionar todos os endereços num raio de 5KM, ficaria assim:
SELECT * FROM tb_address WHERE DISTANCE(latitude, longitude, 51.5375, -0.1933) < 5;
Onde DISTANCE é uma SP que calcula a distancia entre os pontos dados. (nota que seria pessimo fazer isso fora do banco, porque envolveria trazer todos os dados do banco e processa-los, enquanto dessa forma só trazemos o que realmente atende a condição que precisamos).
Enfim, não quando eu disse que um ORM descarta o uso de SP são quando a SP serve apenas para mapear relacionamentos, que ate hoje foram os casos que eu mais vi em uso (joins complexos encapsulados em SP).
🙂
Show de bola… isso ai é uma SP que atende a requisito de regra de Negócio que é um dos objetos de uso de uma stored procedure ( “…influenciar exatamente a maneira como o usuario/desenvolvedor manipula essas informacoes…”).
Quanto a fazer mapeamento direto entre o dado e a aplicação… isso tem pouca utilidade, mas é possivel que seja uma maneira de fazer transformações nos dados, tais como formatações, calculos, geração de resumos. Você acessa uma estrutura de dados que reflete um registro de uma tabela, mas existem certas transformações que são automaticamente aplicadas. Esse seria um caso.
Existem modelos de dados cuja natureza também não permite um controle através de chaves e outros não é muito trivial também, como em modelos de dados que visão dar suporte a aplicações onde o cliente define seus tipos de dados. E esse é mais um caso onde SP’s podem ajudar em muito.
Opa, já conversamos sobre isso algumas vezes, legal ver o artigo aqui.
Eu particularmente acho que o banco de dados deve conter apenas a parte de persistência. A persistência faz parte do modelo, e “conversa” com as regras de negócio, mas não é todo o modelo e na minha opinião não deve conter todas essas regras. Juntar tudo em um bolo só é criar acoplamento desnecessário.
Existem as regras da própria persistência, que podem ser expressas sempre com chaves estrangeiras, campos nuláveis e tipos de dados, em conjunto com uma boa aplicação das normas formais. Isso já trará segurança suficiente pra afirmar que não existem dados inconsistentes no banco de dados.
A aplicação por sua vez deve partir da premissa que não existem dados inconsistentes no banco de dados, e construir as regras de negócio em cima disso. Quando você começa a misturar as regras dessas duas camadas distintas em uma única rotina, você tem um problema de acoplamento, e aí começam as dores de cabeça pra manutenção e testes.
Aliás, falando em testes, como seria o conjunto de testes unitários de um modelo de dados baseado em procedures?
http://pgtap.org/