sincronização de dados de aplicações - rodando o novo aplicativo em conjunto com o legado

Question

Estamos no processo de substituir um sistema legado. Não vai ser um período de tempo com ambas as aplicações executadas em conjunto. Os usuários serão capazes de usar qualquer sistema eo desafio é ser capaz de manter suas bases de dados em sincronia uns com os outros.

O novo sistema é ASP.NET eo legado é VB6. Ambos estão sendo executados em um banco de dados SQL Server. Não está claro neste momento, se os bancos de dados será na mesma sala de servidor, e muito menos do mesmo país.

As duas soluções sobre a mesa até agora são:

1. Serviços da Web que se sentam em cada máquina e é chamado pela outra aplicação.
   • necessidade de modificar o método Save na classe base (es?) Para os objetos nativos. Esta é invasivo e pode ser um problema quando se trata de desligá-lo.

2. Um serviço de balcão único que as pesquisas cada banco de dados e trabalha para fora o que mudou e atualizações para a frente adaptadas conforme o caso.

   • Necessidade de alterar os esquemas em ambas as aplicações para garantir que eles têm um LastModified (DateTime) em todas as mesas para que possamos fazer um SELECT periódica em um determinado intervalo.

Ambas as soluções parecem razoáveis. Ambas as soluções têm vantagens e desvantagens. O negócio pediu para não mais do que um atraso de 2 segundos (!) Entre atualizar um sistema e vê-lo em outro. Isso é, possivelmente, uma meta arrojada mas é algo a apontar para.

Outros que foram sugeridas, mas rejeitadas (eu estou disposto a reconsiderar) são:

• gatilhos de banco de dados (blugrh)
• BizTalk ou outro ônibus (parece uma marreta e é muito complexo para uma solução switchover)
• Modificar todos os procedimentos armazenados (noooo.)
• SSIS (não sei o suficiente sobre isso ainda)

Apreciar quaisquer pensamentos que você pode ter.

EDIT: N. B. Os esquemas são completamente diferentes.

Answer 1

No final, isso foi resolvido com um webservice. Funcionou muito bem.

Answer 2

2 segundos, que é um cronograma muito apertado, e eu estou supondo que a solução de aplicativos suas janelas só pode não cortá-la, não se há centenas de mudanças ou qualquer coisa de uma só vez, eo tempo de pesquisa tem que ser quase cada segundo de esperança para torná-lo dentro de 2.

As bases de dados utilizando a mesma estrutura? Se assim for, eu olhar para a implementação de replicação.

Editar

Após o comentário e além de que os esquemas são completamente diferentes, eu tenho que dizer que realmente vejo dois conjuntos de operações.

1. Modificar as opções de armazenamento de dados no aplicativo para fazer inserções / atualizações / exclusões em ambas as tabelas. Vantagem: imediata, sem processo externo para compartilhar. Desvantagem: tem que modificar todo o código, difícil de desativar etc

.

2. Criar um aplicativo de sincronização, como você mencionou, a sincronização de dados alterados. Vantagem: pode simplesmente desativar após a transferência feito. Desvantagem: muito complexo para escrever especialmente se houver um grande número de mesas. Além disso, não tão rápido, 2 segundos, vai ser muito difícil de realizar

Answer 3

Pessoalmente eu gostaria de rejeitar a idéia de usuários que utilizam qualquer sistema simulataneously. Como você está indo para resolver o problema se o usuário 1 alterado ficha 1 no sistema 1 e 2 usuário registro alterado 1 de uma maneira diferente no sistema 2?

Além disso, se você não precisa de pessoas a usar o novo sistema, eles não vão. A resistência à mudança é muito forte na maioria das organizações.

Eu sugeriria vez que você rollout do novo sistema e exigir que todos usá-lo e horária enviar dados para o sistema antigo para o caso de precisar reverter por qualquer motivo.

Eu não vejo nenhuma maneira razoável de obter uma segunda sincronia 2. Essa é uma exigência ridícula e o lado do negócio deve ser dito assim, em termos inequívocos.

Às vezes você apenas tem que lutar para trás quando os usuários busines quer algo razoável.

Answer 4

O que você descreve aqui me faz sentir como no meio de um pesadelo! Eu acho que você deve primeiro começar a deixar claro para todo mundo que é impossível (ou pelo menos extremamente caro) para pensar em ser capaz de permitir que os usuários a atualizar todos os dados através de 2 aplicação diferente com 2 bancos de dados diferentes durante todo o processo de transição ! Não estou sequer a falar sobre a 2 segundos de atraso ...

Segundo a mim, a estratégia básica deve ser gradualmente interruptor direitos de atualização de dados e possibilidades do legado para o novo aplicativo. Os usuários serão capazes de ver os dados de ambos os lados, mas será capaz de atualizá-lo apenas através de um dos aplicativos.

(incidentaly, este método também irá forçar os usuários a mudar gradualmente para a nova versão, evitando esperado e emissão resistência irritante já exposto por @HLGEM )

Uma vez que esta regra é claramente aceita, você poderia, então, implementar as seguintes etapas.

1. Definir todos os procedimentos que permitam a transferência de dados a partir de banco de dados legado para o novo banco de dados. Eu acho que você precisa para executá-los algumas vezes nos próximos meses ...
2. Coloque todos os procedimentos que permitem a transferência de dados para o outro lado (transferência de dados inversa)
3. grupos homogêneos Aqui você deve ter identificado de tabelas que podem ser movidos juntos. Mesclar o código anterior de uma forma que você terá para cada um destes grupos um procedimento de "transferência de dados" e uma "transferência inversa".

Então, para cada um destes grupos

4. Coloque suas restrições de atualização através de código ou a nível de banco de dados
5. Execute o procedimento de "transferência de dados"
6. Organizar o procedimento de "transferência inversa" como um gatilho no novo banco de dados

Eu acho que o primeiro tipo de dados que você vai ser capaz de transferência será listas que não contêm quaisquer chaves estrangeiras.

Trabalhando desta forma, você vai gradualmente passar de uma situação em que você tem

• leitura / gravação legado aplicativo + somente leitura novo aplicativo

para

• legado aplicativo somente leitura + leitura / gravação novo aplicativo.