Estou trabalhando com um aplicativo herdado que possui cerca de dez anos de dados de clientes. A maioria desses dados não é usada nas operações do dia-a-dia, mas há um requisito de negócios para ter os dados disponíveis para o cliente até sua aposentadoria do sistema.
Estamos explorando o arquivamento dos dados em uma cópia do banco de dados existente e, em seguida, a eliminação dos registros da produção após um determinado ponto no tempo.
Minha preocupação é que o banco de dados passa por uma mudança substancial de esquema a cada trimestre devido aos esforços de desenvolvimento.
Se eu fosse arquivar uma cópia espelhada dos dados, também precisaria aplicar todos os scripts de alteração que vão contra a produção?
Existem estratégias alternativas? Parece que não importa a forma de armazenamento que você escolher (ou seja, banco de dados, arquivos simples, xml), você sempre precisará de alguma forma de mapear os esquemas mais antigos para os mais novos.
Você precisa definir seus requisitos mais especificamente antes mesmo de pensar em uma solução:
Por que o arquivamento é necessário? Parece que o sistema já lida com dados antigos, então qual é a necessidade comercial de separar esses dados? Atuação?
Os dados do arquivo são um instantâneo somente leitura ou são possíveis alterações nos dados históricos? Se forem possíveis alterações, quais tipos de alterações serão suportadas (inserir, atualizar, excluir ou alguma combinação delas)?
O banco de dados é multilocatário e, em caso afirmativo, você exige que cada locatário possa arquivar em diferentes pontos no tempo?
Seu aplicativo precisa ser executado com os dados arquivados como fonte de dados? Presumo que sim, já que você mencionou a sincronização de alterações de esquema.
Qual é a versão/edição mínima do DBMS que você precisa para oferecer suporte? Isso determinará quais recursos estão disponíveis para uso em sua estratégia.
Quanto tempo você tem para implementar o arquivamento? O arquivamento é um problema de design de nível muito baixo que, idealmente, deve ser incorporado desde o início; adicioná-lo mais tarde pode levar um tempo significativo para redesenhar e implementar.
Agora, tendo dito tudo isso, uma coisa que eu aconselho a você, tendo feito isso aqui (SQL Server), é o seguinte: evite vários bancos de dados, se possível , principalmente se você precisar da capacidade de editar dados históricos.
Embora eu não possa revelar nosso IP, direi que o processo envolvido no embaralhamento de dados do banco de dados "ao vivo" para o banco de dados "arquivo" é extremamente complexo se você adotar uma abordagem dinâmica como fizemos para ~ 700 tabelas . Dependendo do estado do esquema do seu banco de dados, esse tipo de coisa pode nem ser possível de realizar ou resultar em discrepâncias de dados inesperadas. Se você não tiver muitas tabelas (< 200) e o esquema estiver em estado bruto, honestamente, não adote uma abordagem dinâmica ou espere até que seja limpo para um estado decente. Com um grande número de tabelas e um esquema aproximado, vários bancos de dados não são uma solução viável.
Como você mencionou, você precisa executar scripts de atualização em vários bancos de dados e controlar todos os bancos de dados de alguma forma. É muito fácil as coisas ficarem dessincronizadas, ou seja, um banco de dados de arquivo é movido para um servidor ou instância diferente e seu banco de dados ou tabela de configuração mantém as informações antigas. A escolha é sempre sincronizar o esquema ou escrever aplicativos para serem sempre compatíveis com versões anteriores. (Dica: é muito mais fácil sincronizar o esquema.)
Embora eu certamente não recomende vários bancos de dados, é uma solução possível, dependendo de seus requisitos.