[firebase-br] Sincronização de base de dados remota

[Marcos Weimer]

Bom, segue um "raciocionio"....

no lado do servidor principal

- Servidor de banco principal (esse vai o principal, como o nome ja diz, ele
vai receber e enviar os dados para os demais)
- Webservice - envio (este recebe a solicitação dos demais servidores, vai
no banco de dados, busca as informações necessárias (alteradas), transforma
tudo em um XML e retorna para quem solicitou)
- WebService - recebimento (este recebe os dados novos/alterados para serem
inseridos no banco principal, e consequentemente sendo disponibilizados para
os outros servidores)
- o webservice roda sobre um servidor web com suporte a
ASP.NET<http://asp.net/>(IIS vem no windows server / windows 7, basta
marcar nos componentes do
windows)
* IIS é um servidor web da microsoft
* É possivel rodar ASP.NET <http://asp.net/> em apache, desde que se tenha
paciencia e persistencia, com o IIS é facil, poucos clicks e esta tudo
rodando

no lado dos clientes
- programa rodando em paralelo com o seu sistema (um programa por banco
"filho", então uma filial com vários computadores só vai precisar rodar um
programa para sincronizar os dados, normalmente no servidor), este programa
não é complexo, apenas um timer e as SQLs para enviar/receber os dados, não
é dificil, apenas trabalhoso, depende de quantas tabelas o seu sistema
possui.

no banco de dados
- Criar em todas as tabelas que forem sincronizar uma campo timestamp que é
atualizado por trigger. (aqui usamos DATA_CRIACAO_ALTERACAO e é atualizado
por trigger a cada insert/update, este campo vai nos "dizer" se vamos
sincronizar ou não este registro com base na tabela de referencias
- Criar uma tabela de referencia, onde vai conter a filial, a data/hora da
ultima sincronização e a tabela (tanto no banco principal quanto nos
filhos), para enviar alguma informação vamos nesta tabela, lemos o ultimo
envio e selecionamos alterados/inseridos após a ultima sincronização, o nome
da tabela neste caso, é importante no caso de termos várias tabelas para
serem sincronizadas e a conexão cair, ai não temos o problema de pegar uma
tabela "grande" mais de uma vez.

no mais é trabalhar com transactions para evitar de duplicar registros,
ocorrer erros e ficar com "meia" sincronização salva.

Usamos algo parecido aqui para PDV que precisa trabalhar off-line (conforme
legislação atual) e para vendedores externos a empresa poderem fazer seus
pedidos, cadastrar novos clientes e afins.

É questão de dimensionar oque precisa ser sincronizado e se adequar.

Se for o banco todo, com muitas tabelas, vai ter uma trabalheira danada.

Uma questão importante tb é sempre verificar usuario/senha para
enviar/receber os dados, segurança nunca é "demenos", se seu sistema não
possuir este cadastro tb deverá ser implementado.

Não sei se fui claro, qq coisa vão perguntando ae.

flw

P.S. - estou reenviando sem a msg anterior e tal pq cai no limite de tamanho
da msg.

-=Ma®©oS=-
Marcos R. Weimer
Puma GTE 1974 Tubarão