Com alguma periodicidade, isso precisa ser feito:
- Inserção de dados de um banco de dados de produção em um banco de dados de teste/desenvolvimento, para que os programadores tenham novos dados para testar.
- Migrar dados de um banco de dados para outro, por qualquer motivo.
Nota: os bancos de dados são relacionais.
O problema é:
- Os bancos de dados foram modelados com uma política "all-PK-are-surrogate".
- Mover dados de um banco de dados para outro envolve programação para evitar a colisão de valores de PK (gerados por sequências).
- Uma tabela pareando os valores das PKs das tabelas do banco de dados de origem e destino é necessária para fazer a "equivalência" entre as chaves substitutas.
- A referida tabela deve ser criada antes da migração, combinando chaves de negócios (que não são PK, portanto, não controlam FKs)
- A migração de dados mesmo de uma única tabela não é trivial, ao contrário de tabelas com chaves naturais.
Qual é a maneira mais fácil de copiar linhas de um banco de dados para outro quando todas as tabelas têm chaves substitutas?
Nos deparamos com esse problema (ou pelo menos semelhante) há pouco tempo no trabalho, e nossa solução é dividir o processo de migração em etapas:
A segunda parte é a complicada, mas no nosso caso conseguimos seguir este algoritmo para cada tabela:
Repita para cada tabela de preparação. Quando todas as tabelas de preparação forem processadas, INSIRA os dados nas tabelas de destino.
Uma suposição em que isso se baseia é que todos os dados são novos e independentes dos dados já existentes no banco de dados.
Abordagem alternativa se você não precisar disfarçar os dados por motivos de privacidade. Todas as alterações de banco de dados e valores para tabelas de pesquisa devem estar no controle de origem. Simplesmente restauramos o último backup de prod e, em seguida, usamos scripts de controle de origem para adicionar quaisquer alterações de desenvolvimento que ainda não tenham sido feitas no Prod. Se você tiver vários bancos de dados, todos devem ser atualizados ao mesmo tempo. Uma vantagem disso é que você tem aproximadamente o mesmo número de registros que prod, o que faz uma grande diferença ao testar o desempenho do código do banco de dados. Ele também ajuda a manter seus desenvolvedores usando o controle de origem para alterações e ajuda a praticar implantações antes de movê-los para outros ambientes.