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.
Essa pergunta é uma provocação. Para aqueles que como eu trabalham com TI há tempos, a resposta é contraditória. Se por um lado a Internet e mais recentemente a computação móvel abriu um mundo de possibilidades, está cada vez mais complexa a construção de sistemas para atenderem as demandas do mercado.
Quem usa um smartphone ou tablet não se dá conta que tem nas mãos um computador com capacidade de processamento maior que PCs da época que comecei minha carreira profissional (ver The Future of the Smartphone). Entretanto para quem desenvolve uma aplicação corporativa para esses aparelhos tem um desafio que também é maior em relação ao que se fazia no tempo do DOS.
Fiz a ressalva de que a complexidade de desenvolvimento de aplicações corporativas aumentou porque a construção de aplicativos que exploram recursos do dispositivo (jogos e manipulação de mídias, por exemplo) é relativamente simples, como era de se esperar. A questão é que para as empresas realmente ganharem dinheiro com os usuários de dispositivos móveis elas necessitam oferecer serviços.
Um serviço na perspectiva atual, onde a computação se encontra em todos os lugares, seria uma forma de ganhar dinheiro com o atendimento das necessidades e desejos dos clientes. Para isso ela deve coletar, processar e extrair resultados de dados que trafegam a taxas cada vez mais altas e com um volume cada vez maior de atualizações. Isso leva a um conjunto de requisitos como disponibilidade e segurança que são difíceis de realizar. Por exemplo, o Facebook se destacou da concorrência por garantir um downtime muito baixo, graças a uma combinação de programação mais equipamentos capazes de prover essa confiabilidade.
Segurança é particularmente um aspecto difícil de implementar. Por mais que os fornecedores de sistemas operacionais e demais softwares usados para execução de sistemas trabalhem, sempre há brechas sendo descobertas. E esse aspecto é relegado tanto na formação profissional como na hora em que se negocia os recursos para desenvolvimento de aplicações.
O desenvolvimento de sistemas não evoluiu como esperado porque a computação atual demanda um conjunto de computadores rodando softwares especializados para ter no ar serviços que interessem aos usuários. Cada um desses computadores – servidores de banco de dados, application servers e dispositivos dos usuários (para ficar apenas nos mais óbvios) demandam ferramentas de programação específicas. Tudo isso tem que funcionar de forma coordenada e em caso de mudanças todos precisam atualizar-se de forma sincronizada. Ou seja, há muitos pontos de falha e lei de Murphy garante que estas acontecem…
Para simplificar a TI, deve-se começar com esse questionamento. Ao se buscar respostas para essa essa pergunta, ve-se aspectos que no dia a dia não estão claros para os profisisonais da área, mesmo os mais experientes. Um dos jargões da moda – “pensar fora da caixa” – realmente faz sentido nesta situação.