Qual é a maneira mais lógica de armazenar várias versões de um banco de dados em uma instância do SQL Server?

Question

Operamos um site na AWS que usa o Azure como fonte de dados. O Azure é preenchido por replicação transacional de nossos clientes. Uma vez a cada 3 ou 4 meses, uma nova versão do banco de dados do cliente é liberada. Minha empresa não faz esse banco de dados de clientes. Na maioria das vezes, a nova versão não vem com um script de atualização e todas as informações do cliente são apagadas e a nova versão do banco de dados é criada recentemente.

Como faço para manter um histórico ininterrupto dos dados do cliente na nuvem por meio dessas atualizações? Eu vejo apenas duas opções: criar um novo banco de dados para cada versão, crie um novo esquema para cada versão. O primeiro vai ficar caro ao longo do tempo, o segundo se sente hacky. Se é tão importante eu deveria fazer meus próprios scripts de atualização?

    

Answer 1

Como você precisa manter dados históricos, bem como a versão do banco de dados, você pode usar o flyway para criar uma linha de base do seu banco de dados e depois migrá-lo para as novas versões depois de ter o DDL. O Flyway manterá o histórico de versões para você e você poderá ver suas atualizações usando metas do maven com seus perfis de banco de dados. Você não precisa usar o maven, você pode usar o flyway da interface de linha de comando.

Essencialmente, ele satisfaz sua segunda opção usando uma ferramenta para que você possa repetir os processos em diferentes ambientes (por exemplo, DEV, QA, Staging, PROD). Você usaria apenas perfis diferentes no seu processo de migração.

Aqui está o software que você precisará: link