Trabalhei principalmente no desenvolvimento de aplicativos de negócios e gerenciamento de configuração. Sua pergunta é representativa para os desafios em tal ambiente; quando você atualiza, por exemplo, o Microsoft Word, não precisa alterar todos os documentos imediatamente de doc para docx. E os documentos ainda possuem uma estrutura mais simples, um banco de dados de relacionamento completo.
Não é assim para aplicativos de negócios; os usuários pulam lançamentos, fazem alterações não autorizadas no modelo de dados e o sistema precisa continuar funcionando e fornecendo os números corretos...
Usamos para nossos próprios aplicativos (o maior deles tem 600 tabelas) uma ferramenta CASE autodesenvolvida que inclui ramificação/fusão, mas a abordagem também pode ser feita manualmente.
Modelo de dados de versão
O modelo de dados pode ser escrito de forma estruturada. Por exemplo, como conteúdo da tabela (CSV a ser carregado em uma tabela com metadados) ou como código que detecta a versão em uso e adiciona colunas e tabelas quando faltam, incluindo migrações não triviais.
Isso permite que vários usuários ao mesmo tempo alterem o modelo de dados.
Quando você usa a detecção automática (por exemplo, usamos uma chamada chamada "verify_column" em vez de "add_column"), isso permite até mesmo uma migração suave, independentemente do número da versão a partir do qual o cliente está iniciando a atualização. Tal procedimento analisa a tabela a ser alterada e emite o DDL correto, como
alter table t1 add col1 number not null quando uma coluna está faltando ou alter table t1 modify col1 not null quando a coluna já estava presente, mas anulável. Para Oracle e SQL Server, posso fornecer alguns procedimentos de amostra. No MySQL eu codificaria isso usando uma linguagem do lado do cliente, de preferência independente do sistema operacional para permitir que as instalações fossem executadas no Windows e no Linux. Talvez usando Apache Ant quando você tiver experiência com isso.
Dados de versão
Dividimos as tabelas em quatro categorias:
- R:dados referenciais; dados que o site de aplicação deve fornecer antes que ele realmente use o sistema. Por exemplo, códigos de conta do razão geral. Os dados referenciais raramente mudam após o lançamento e não crescem continuamente em tamanho. O conteúdo reflete o modelo de negócios do site onde o aplicativo é usado.
- T:dados da transação; dados que o site registra, altera e remove durante o uso do aplicativo. Por exemplo, entradas do razão geral. Os dados da transação começam em 0 e crescem continuamente. Quando a receita da empresa dobra, os dados de transações também dobram.
- S:dados semeados; dados NÃO mantidos pelo usuário no site, mas fornecidos e mantidos pela parte desenvolvedora. Essencialmente, este é o código transformado em dados. Por exemplo, 'F' significa 'Feminino'. Erros nos dados propagados podem levar a erros do sistema.
- O:o resto (idealmente não é necessário, pois são técnicos, mas alguns sistemas exigem uma tabela temporária A ou uma tabela de rascunho B).
O conteúdo das tabelas da categoria 'S' (dados semeados) é colocado sob controle de versão. Nós normalmente os registramos como metadados em nossa ferramenta de caso, então chamados de 'conjuntos de dados', mas você também pode usar, por exemplo, o Microsoft Excel ou até mesmo código.
Por exemplo, no Excel, você teria uma lista de linhas de dados propagados. Na coluna A você pode inserir uma função do Excel como
=B..&"|"&C..& "|" & ... que concatena tudo e o torna adequado para carregamento por uma ferramenta carregadora. Por exemplo, no código, você pode ter uma chamada como:
verifySeed('TABLE_A', 'CODE', 'VALUE')
O Excel é um pouco difícil de colocar sob controle de versão, permitindo que vários usuários alterem o conteúdo ao mesmo tempo. A abordagem com código é muito simples.
Lembre-se também de adicionar recursos para remover dados propagados obsoletos. Por exemplo, listando explicitamente dados propagados obsoletos ou removendo automaticamente todos os dados propagados presentes nas tabelas, mas não tocados pela última instalação.
