SQL Source Control liga-se ao SSMS e liga as suas bases de dados ao seu sistema de controlo de versões, permitindo-lhe controlar os seus esquemas de bases de dados, e depois implementá-los usando o motor de comparação SQL Comparar de confiança do Redgate.

A última versão (enviada esta semana!) apresenta uma versão melhorada de scripts de migração, que lhe permite escrever o seu próprio SQL para substituir o script de implementação gerado pelo SQL Compare, tornando possível aos seus colegas de equipa obter as últimas alterações do controlo de origem sem o risco de perder dados. Pode saber mais sobre o que fizemos, e porquê, noutra publicação recente no meu blog.

Mas aqui, queria falar consigo sobre como funciona, utilizando um cenário comum.

Como evitar a perda de dados ao renomear uma tabela

Tarefas comuns que podem ser afectadas incluem dividir ou fundir colunas e tabelas, adicionar uma restrição NÃO NULL a uma coluna, alterar o tipo ou tamanho dos dados de uma coluna, e renomear uma tabela.

No caso de renomear uma tabela na sua base de dados de desenvolvimento, o SQL Source Control interpretaria esta alteração como um DROP e CREATE. Se outro membro da sua equipa utilizar o separador Get latest para obter estas alterações, os dados na tabela de destino são perdidos.

Para evitar esta perda de dados, pode escrever um script de migração para renomear a tabela utilizando o procedimento sp_rename armazenado. Este script substitui as instruções DROP e CREATE que o motor SQL Compare geraria para esta alteração.

Após ter renomeado a sua tabela (neste caso de utilizadores para clientes) o próximo passo seria submeter as alterações ao seu sistema de controlo de origem usando a tabulação Commit changes in SQL Source Control. O SQL Source Control avisá-lo-á de que pode ocorrer perda de dados ao submeter a alteração e sugerir-lhe-á que escreva um script de migração.

Na tabulação Migrations e em Replace uncommitted schema changes, utilizaria então as caixas de verificação para seleccionar as alterações de esquema relevantes.

Neste exemplo está a substituir as alterações de esquema não comprometidas porque já renomeou a tabela, mas ainda não a submeteu. A renomeação é na realidade interpretada por SQL Compare como um DROP e CREATE e o script de migração irá substituir essas alterações no script de implementação (a outra opção seria começar com um script em branco, o que faria se já tivesse preparado o seu esquema para a migração e comprometido essas alterações).

Ao clicar em Generate script SQL Source Control gera um script de migração baseado nas alterações não comprometidas e pode então substituir as declarações DROP e CREATE geradas automaticamente.

este caso usaríamos o seguinte SQL:

EXEC sp_rename 'dbo.users', 'customers'GO CREATE SYNONYM dbo.users FOR customersGO

O sinónimo para a tabela de clientes aqui evitará problemas onde a tabela é referenciada usando o nome antigo.

Então pode Guardar e fechar e este script de migração substitui agora as alterações feitas.

Voltar na tabulação Comprometer verá o script de migração com as alterações de esquema associadas aninhadas por baixo. Depois só precisa de seleccionar o novo script de migração, introduzir um comentário e submeter as alterações.

Está agora pronto para implementar as alterações. Se estiver a utilizar o SQL Compare então o script de migração é automaticamente executado durante a implementação, utilizando o procedimento sp_rename armazenado no lugar do DROP e CREATE declarações originalmente geradas pelo motor SQL Compare.

Como posso utilizar scripts de migração no SQL Source Control?

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *