No desenvolvimento de softwares empresariais - aqueles voltados para execução de processos nas organizações - o uso de SGBDR (Sistemas de Gerenciamento de Banco de Dados Relacional) como meio para armazenar informações é regra corrente. Vale observar que há outras abordagens para a questão de como guardar informações (como NoSql), porém o modelo relacional está bastante consolidado e possui uma ampla base de conhecimento sobre como aplica-lo.
Considerando que o sistema a ser desenvolvido usará banco de dados, quem desenhar a arquitetura da solução precisará decidir sobre a forma como as informações serão lidas e atualizadas. Para auxiliar na escolha, devem-se pesar os prós e contras de cada uma das alternativas que forem analisadas.
Assumindo que a maior parte do desenvolvimento nas empresas está baseado em linguagens orientadas a objeto (Java e as suportadas pelo .NET Framework), o problema a resolver está na transformação de dados vindos do modelo relacional para representação de objetos (também conhecido como Impedance Mismatch). De uma forma bastante simplificada, o modelo relacional é anterior à orientação a objetos e consequentemente não suporta técnicas como o uso de interfaces e herança entre objetos.
Um dos melhores artigos que já li na internet – The Vietnam of Computer Science – trata especificamente desse assunto. Há uma introdução falando da Guerra do Vietnam, que é a analogia que o autor faz com as restrições ao uso de ferramentas de ORM (Object-Relational Mapping), que oferecem mecanismos para transformar dados relacionais em objetos. Segundo o artigo, sucessos iniciais que se atingem ao usar ORM acabam levando a um ponto onde não se consegue ter mais retorno, mesmo aumentando o investimento no uso da ferramenta. Já se passaram anos de sua publicação e ele continua atual, mesmo com a evolução de frameworks como o Hibernate e o Entity Framework.
Sem tomar parte na polêmica, um ponto comum nas diversas abordagens para ORM está no uso de queries parametrizadas. Na prática isso significa que as instruções SQL são montadas na aplicação que usa o banco de dados. Normalmente a ferramenta gera essas instruções de forma transparente ao programador e as submete ao banco. Consequentemente estas dão grande produtividade no desenvolvimento de sistemas baseados em SGBDR.
Outra maneira de ler e gravar informações em banco de dados está no uso de stored procedures (SPs) Elas encapsulam as instruções SQL em código que é executado no próprio banco de dados. Hoje algumas das ferramentas de ORM (como as citadas acima) dão suporte ao uso de SPs, mas é necessário levar em conta que as procedures demandam uma codificação adicional. E deve-se lembrar de que cada SGBDR possui a sua própria sintaxe para essa codificação.
Dois pontos a destacar em favor das stored procedures seriam desempenho e segurança. Os SGBDR validam o código de uma SP ao gravá-la, assim em tempo de execução ele já executa o processamento, dispensando a necessidade de conferir se a instrução SQL está correta. Do ponto de vista da segurança, SPs diminuem a superfície de ataque a um SGBDR. Para acessar os dados num SGBDR é feita uma conexão usando uma conta de usuário do banco. Ao se dar os acessos necessários para executar instruções SQL, pode-se expor o banco de dados a vulnerabilidades do tipo SQL Injection. Quando são usadas SPs, esse tipo de vulnerabilidade é bastante mitigado, por exemplo, dando acesso somente para execução destas à conta de usuário do banco.
Para escolher qual a forma com que as informações serão recuperadas de SGBDRs, considere que há três requisitos para ponderar: produtividade, desempenho e segurança. Como eu particularmente gosto de usar SPs, uma sugestão para aumentar a produtividade no uso delas está na extensão de geradores de código normalmente associados a ferramentas de ORM para que construam as SPs.