Eu "herdei" um aplicativo da web que foi projetado e implementado de maneira horrível (tanto o aplicativo quanto o banco de dados). Por exemplo, os dados principais são armazenados usando uma espécie de armazenamento de valor-chave emulado em um banco de dados Postgres 8.2, tornando praticamente impossível extrair dados úteis dele em um período de tempo razoável.
Atualmente estou trabalhando duro para substituir todo o aplicativo + banco de dados, no entanto, levará alguns meses até que o novo aplicativo seja concluído. Isso é um problema, pois o site é muito lento devido ao design extremamente ruim do banco de dados e às consultas ainda piores. Portanto, estou planejando corrigir o design do banco de dados e as consultas no site ativo até que o site tenha um tempo de carregamento aceitável como uma solução temporária.
No entanto, tenho algumas limitações para contornar, as mais problemáticas são:
- Terei que fazer tudo de dentro de um CMS de construção proprietário.
- As consultas são todas distribuídas em muitos arquivos e não há como procurá-los. Portanto, é quase impossível garantir que atualizei todas as consultas para uma tabela específica.
- Não tenho acesso direto ao banco de dados, mas posso executar consultas usando um editor de consultas no CMS, mas apenas para tabelas pertencentes ao aplicativo (portanto, não há tabelas pg_* para mim).
- Não tenho acesso a um ambiente de desenvolvedor, nem posso criar um. Tudo tem que ser feito ao vivo.
Então, basicamente, terei que migrar um banco de dados ao vivo ao longo de alguns dias, ao mesmo tempo em que atualizo o aplicativo ao vivo para que ele possa lidar com o novo aplicativo, sem poder pesquisar o uso de cada tabela.
Com todas essas desvantagens levadas em consideração, elaborei o seguinte plano:
- Crie tabelas inicialmente vazias para armazenar os dados de maneira sã.
- Crie gatilhos nas tabelas antigas que podem sincronizar os dados com os novos.
- Exporte os dados das tabelas antigas para as novas tabelas e ative os gatilhos.
- Substitua as consultas uma a uma.
Usando esta estratégia, terei 2 bancos de dados sincronizados após a etapa 3. Inicialmente, todas as consultas irão para o banco de dados antigo, mas enquanto estou atualizando as consultas lentamente, o banco de dados antigo será menos usado e o novo mais.
Levando em consideração essa situação "subótima", essa é uma boa estratégia para corrigir alguns dos problemas? Que coisas devo levar em consideração ao fazer isso?
Observe que entendo perfeitamente que esta é uma missão suicida muito arriscada. No entanto, terei que fazer algo em um curto espaço de tempo, caso contrário, o site ficará totalmente inutilizável.
Se puder, seria melhor fazer exibições e gatilhos em vez de replicação bilateral de dados entre os dois lados.
Então, eu modificaria um pouco seu plano:
Crie um esquema são
Crie uma emulação do esquema antigo usando visualizações.
Crie gatilhos nas exibições para gravar no novo esquema em vez do antigo.
A questão é o que vem depois disso. Como você está construindo uma nova ferramenta, é bom estar no modo de manutenção. Isso significa, penso eu, corrigir apenas as consultas mais lentas que causam problemas.