Até que ponto a modelagem do banco afeta o desenvolvimento OO?

Sim, influencia e muito.

No seu caso, já que vão trocar tecnologia, eu aproveitaria e trocaria o Access.

Inté.

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.

Velhinho

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.

Boa sorte na empreitada.
Deus abençoe

\o/

Se a “diretoria” não quer, o problema não é a tecnologia.

Mas claro, nada nunca é culpa dela, não é mesmo?

Respondendo a pergunta titulo do tópico:

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.

flws

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?