A IBM é uma empresa que não inova. Deixou de ser o grande líder do mercado há décadas para se tornar um seguidor, e dos bem fraquinhos. O IBM AlphaWorks, entretanto, é uma das poucas coisas que sobrevive em termos de inovação da IBM. Eu recebo a newsletter há alguns anos e é sempre uma das primeiras mensagens a serem lidas quando chegam.
Talvez por essa esperança toda que me decepciona fortemente ver que as pessoas ainda, em 2007 (notou que “em 2007″ é uma expressão recorrente minha há algum tempo?) as pessoas ainda insistem em conexões com bancos de dados feitas pelo cliente. Saber disso realmente é frustrante como desenvolvedor.
Bancos de dados como coração da empresa já foram uma técnica válida. Era o único middleware que prestava ou era viável no cenário de algumas muitas décadas atrás. Hoje as pessoas querem SOA, querem componentes reutilizáveis e… continuam insistindo em repositórios de dados centralizados.
Certa vez a equipe que eu coordenava passou por um problema nessa área. Como parte do lançamento de um novo produto tivemos que eliminar algumas tabelas e mudar o schema de dados. Apesar daquele esquema só ser utilizado completamente pela minha equipe, sabíamos que algumas pessoas estavam fazendo consultas neles. Alguns greps no CVS (infelizmente não usávamos SVN) e vimos que três projetos usavam as tabelas que eliminamos e que quase todos usam as outras. A solução do mundo dos SGBDs corporativos é uma só: faça uma view e mantenha ela no ar enquanto as pessoas não alterarem, testarem, homologarem e instalarem seus sistemas modificados.
Esta foi uma epifania, as pessoas acordaram e vimos que precisávamos racionalizar isso. A solução veio na forma de um arquivo JAR que continha um cliente padronizado fazendo consultas em JDBC diretamente ao banco de dados. Eventualmente construímos alguns WebServices REST (como quase sempre, SOAP não fazia sentido) e os clientes que se conectavam ao banco foram migrados para versão que conectava-se ao REST. Quem teve o trabalho de se adaptar a primeira versão não precisou de mais anda para migrar para uma arquitetura SOA.
Quantas vezes vamos ter que resolver este mesmo problema até que todos percebam que bases de dados são apenas partes de sistemas?
Yeah! Ótimo post!
Só porque dá menos trabalho (se é que dá), não significa que uma solução seja mais simples. Fazer as coisas pior de propósito é uma lástima…
Você não sabe a tristeza que é participar de um projeto p/ refazer todo um sistema e na versão nova ter todo o esquema de acesso feito através de BD.
No meu caso, é fazer a migração de um sistema Mainframe p/ um em Java, que será acessado via procedures, os old-timers aqui enchem a boca p/ falar que estão construindo um sistema cliente-servidor.
Sua solução foi boa, mas justamente porque as bases de dados são o coração do sistema.
O que você fez foi colocar uma camada adicional, o que foi necessário porque os SGBDs SQL não são realmente relacionais, contendo entre outros problemas restrições arbitrárias sobre visões atualizadas que complicam a solução correta do problema; e não contendo todas as regras organizacionais como restrições de integridade declardas.
Mas as bases continuam sendo o coração.
Leandro,
Ainda que o banco fosse compeltamente relacional, como eu faço quando eu removo tabelas e não quero quebrar minhas aplicações existentes? O que eu faço quando decido que preciso migrar para uma versão mais nova do banco de dados e não posso atualizar as alicações que a usam hoje? Se sua resposta envolver mantêr views para o sistema legado eu não a considero válida. Isso é um sintoma de uma arquitetura que não deveria ser usada para integração, não possui contratos, não suporta mudanças e vai contra algumas décadas de pesquisa em interação de sistemas.
Ainda que um modelo relacional “de verdade” me ofereça possibilidade de não quebrar uma aplicação porque eu alterei meu schema -coisa que não faz- eu ainda teria que sentar e esperar alguem criar uma base de dados relacional “de verdade”.
Bases de dados não são o coração de nada, os dados em si é que são importantes. Como você os mantêm, se num SGBD relacional, OO, em arquivos texto ou o que quer que seja, depende da aplicação.