Pessoal tenho duas migrações de dados para fazer e gostaria de saber se utilizar o java é uma boa idéia para essas migração.
Exemplo: Existem três bancos. Banco A, B, C
B e o C tem que se adequar ao banco A ou seja devo migrar o B e C para o A, mas os três bancos não possuem a mesma estrutura, sendo assim na codificação do programa terei que preencher algumas lacunas para que os bancos B e C se adeque o banco A.
Estou pensando em fazer um por um para evitar problemas já que as estruturas são diferentes, pensei eu criar duas conexões para o programa que irá migrar os dados, logo depois mapearei a estrutura dos dois bancos exemplo banco A e B, apartir dai criarei métodos que sugara os dados do B e gravará no A, do mesmo modo será feito para o banco C.
O que acham, será que vira com java ou melhor utilizar outra forma?
Olha, na minha opinião o overhead para passar do banco para a aplicação Java, e de volta para o banco, é impeditivo para quantidade de dados de médio para grande volume. Imagine que vc fará uma consulta no banco, que carregará em memória seus dados, depois vai transportar para a rede, carregar na memória no programa Java, processar, transportar pela rede novamente… Enfim, I/O demais…
Trabalhamos e gostamos de Java, mas existe a ferramenta certa para cada trabalho. Acho melhor partir para scripts na linguagem do seu DB, como PL/SQL.
Se desejar mesmo fazer upgrades de banco controlados usando Java, recomendo http://www.liquibase.org/.
Recomendo utilizar a ferramenta PDI (Pentaho Data Integration) antigo Kettle, pois esta ferramenta
é desenvolvida para realizar processos ETL bem como migrações de base de dados
[quote=fbdo]
Olha, na minha opinião o overhead para passar do banco para a aplicação Java, e de volta para o banco, é impeditivo para quantidade de dados de médio para grande volume.[/quote]
Tem coisas que vão além do senso comum. Há aplicações que mesmo passar todos os dados para o java e devolvê-los ao banco é mais rápido do que executar o processo via PL/SQL. Tudo é uma questão de teste.
A implementação fica extremamente mais simples se for feita apenas entre dois bancos de cada vez. Além disso, se os SGBD’s forem os mesmos, a coisa fica mais fácil (afinal, a linguagem sql e as tabelas de estrutura são as mesmas). O que pode ser um pouco mais chato é a adequação de constraints diferentes.
Talvez um jeito que dê menos problemas seria:
[list]criar todas as tabelas inexistentes (sem constraints ou validações, apenas colunas puras)[/list]
[list]criar todas as colunas inexistentes (novamente sem constraints ou validações)[/list]
[list]alterar todas as colunas que não sejam restritivas (por ex: transformar Integer em VARCHAR2, ou Varchar2(32) para VARCHAR2(64))[/list]
[list]remover da base destino todas as constraints que não existem na base modelo[/list]
[list]desativar todas as constraints e triggers das tabelas que serão manipuladas[/list]
[list]atualizar os dados (se houverem colunas incompatíveis, deverá estudar caso a caso, aqui o processo tende a ser bem mais chato)[/list]
[list]criar todas as constraints inexistentes (se possivel, sem check constraint, para ir rápido)[/list]
[list]apagar todos os objetos[/list]
[list]criar todos os objetos da base modelo na base destino[/list]
[list]Habilitar constraints (se possivel, sem check constraint, para ir rápido)[/list]
[list]Comparar a estrutura, para localizar possíveis problemas e corrigí-los[/list]
[list]Checar a validação de constraints por tabela (efetuar o processo de checagem de validação de constraint para cada tabela, cheque as tabelas cadastrais e depois as transacionais - Esse processo pode demorar muito, dependendo da quantia de dados em cada tabela).[/list]
[list]Habilitar as triggers[/list]
Enfim, é isso.
Outra coisa, se for usar java e o desempenho for algo importante: Não use Hibernate ou qualquer outro framework “mágico”. Utilize JDBC puro. Vc pode se impressionar com a comparação de desempenho entre hibernate d jdbc puro, é algo absurdo. Uma vez eu fiz um processo desse com hibernate que demorava “apenas” 3 dias para concluir, então eu removi todo o hibernate e coloquei jdbc NO MESMO PROCESSO e a operação demorou apenas poucas horas.
barenko está absolutamente correto, e inclusive deu o caminho a seguir passo a passo.
Como falei, depende muito do volume de dados. Talvez minha opinião esteja enviesada, pela minha experiência com sistemas de operadoras de Telecom, com muitos milhões de registros. Vale o conselho de testar as duas abordagens com uma massa menor para testes.
aqui no serviço fiz um software de migração usando o Spring, ele executa uma consulta em SQL e a cara linha implementando a interface RowMapper do Spring ele percorre registro a registro, e eu convertia em Objetos JPA, vc podeia usar SQL mesmo fazendo os inserts.
Funcionou muito bem, usei para migrar de Firebird (Base de outra pessoa, muito mal modelada por sinal) para a nossa base em Postgresql.
Logico toda a importação tem seus erros, mais foi bem tranquila essa importação.
Pessoal desculpe reviver o tópico mas estou com um problema do nosso amigo rodsm
Preciso migrar de uma base MySQL todo doida (poucas tabelas que fazem muitas coisas) para um bd oracle normalizado.
como você resolveu rodsm
[quote]
22/02/2010 10:28:44 Assunto: Re:Migração de banco de dados com Java
aqui no serviço fiz um software de migração usando o Spring, ele executa uma consulta em SQL e a cara linha implementando a interface RowMapper do Spring ele percorre registro a registro, e eu convertia em Objetos JPA, vc podeia usar SQL mesmo fazendo os inserts.
Funcionou muito bem, usei para migrar de Firebird (Base de outra pessoa, muito mal modelada por sinal) para a nossa base em Postgresql.
Logico toda a importação tem seus erros, mais foi bem tranquila essa importação. [/quote]
Felagund pode falar um pouco mais dessa sua solução?
Estou fazendo o dowload da versão trial do pdi, enquanto isso fico no aguardo de algumas dicas.