Questão “filosófica”: até que ponto a modelagem de um banco de dados interfere no desenvolvimento orientado a objetos?
Tenho um sistema que foi desenvolvido há 10 anos, ele tem seu banco em ACCESS e seu código fonte em VB 5. Como todos os programadores VB da empresa foram extintos, sobrando apenas a galera de JAVA, resolveram migrar esse pequeno sistema, a título de teste, para futuras migrações (há outros em VB).
Ocorre que, durante a migração do sistema para JAVA, foi se tornando impossível contornar os problemas de desenho do banco. Querem um exemplo?
A tabela responsável por armazenar os dados dos empregados simplesmente abriga todas as informações do empregado, ou seja, nome, telefone, endereço residencial, comercial, documentação, enfim, é uma tabela gigante. Nossa DAO ficou horrível pois, para contornar esse problema, criamos alguns métodos que iam montando o empregado aos poucos, conforme a informação fosse necessária, e isso se tornou impraticável com a adição de novas classes, novos relacionamentos, a ponto do ACCESS travar com qualquer consulta à base de dados.
A afirmativa: “o desenho do banco de dados influencia na programação” - parece óbvia, mas só vivenciando o que ela quer dizer que você se dá conta do quão importante é um banco de dados bem desenhado.
E vocês? Já passaram por isso? Alguma solução que eu não tenha contemplado?
Pois é. A idéia inicial era essa, mas ninguém quer migrar para o Oracle se não for pra fazer direito, ou seja, desenhar tudo certinho. Se for fazer isso, é um sistema totalmente novo, o que eu acharia o melhor dos mundos, mas a “diretoria” não quer.
Eu ja trabalhei com Access por um bom tempo.
Ele é bom, pra aplicações pequenas… Sinceramente, o que mais achava atrativo nele, na época, eram as macros e a congregação numa mesma aplicação dos formulários e do banco de dados.
Porém, meu mundo mudou e minhas aplicações tb.
Sinceramente, não aconselho mais ninguém a usar access como sgbd, de forma profissional. Pra testes e aplicações pequenas, talvez.
Porém, no seu caso, aconselho fortemente mudar tb o sgbd.
Se a sua ‘diretoria’ não quer migrar para Oracle, apresente a eles o Postgre, ou o MySQL.
Leve um quadro comparativo, uma pesquisa sobre as vantagens de desvantagens de migrar sistemas legados e, principalmente, de continuar usando o access.
Afeta bastante, inclusive de forma radical. A começar pelo fato do banco de dados utilizado no seu caso, independente de ser oracle ou access, não ser orientado a objetos. Vc está utilizando um banco de dados relacional com uma linguagem orientada a objetos.
Vc pode até dizer “Utilizo JPA / Hibernate e etc… e esqueço que o banco é relacional.”, pode até ser porem se o banco fosse OO vc não estaria utilizando estes componentes de alta complexidade.
O seu problema é bem comum, inclusive o uso de ORMs em banco de dados legados é desmotivada pelas equipes que os desenvolvem justamente pelos problemas (normalização) que vc relatou. Aliás existem outros problemas além deste que vc citou; uso de chave composta como PK é um exemplo.
Este caso é um problema natural resultante da necessidade da evolução do sistema, ou seja, é um caso típico de refatoração como os outros. Se não fizer a refatoração nestas estruturas terá que continuar convivendo com ela, mesmo utilizando um linguagem mais moderna.
Admitindo que a “diretoria” tenha alguma visão da realidade dos fatos (duvido), tente convence-la das vantagens de se aplicar a refatoração nesta base de dados.
Ter uma estrutura de dados ruim em termos de modelagem é pior do que utilizar um banco de dados sem muita sofisticação.
Cara já passei por isto… e o melhor mesmo é refatorar o banco… pois veja o banco já e em algo que na verdade nem um BD é Acess e ainda a modelagem ta toda zuada… ou seja este banco é um tremendo de uma gambiarra… o correto mesmo é criar outro em um sgdb decente se não quer gastar $$$ pode usar o postgrees ou o DB2 Express que é muito bom… e fazer a modelagem do 0 e migrar os dados para ele… é a melhor coisa a ser feita… pois não adianta muito vc ter em Java uma modelagem decente e com um banco lixo… o melhor sem duvidas e refazer a base em outro BD
mas diretoria é um problema… tem que tentar convence-los que terão mais prejuizo a longo prazo com a coisa desta forma…
do que investimento a curto prazo que no final saem no lucro…
Eu penso que o modelo relacional não deveria influenciar no modelo do negócio orientado a objetos, deveria existir um mapeamento entre os dois modelos. (confesso que não é simples de fazer)
Victor lendo seu post fiquei me perguntando, se a mesma funcionalidade funcionava em VB porquê parou de funcionar em JAVA?
