[firebase-br] Sincronização de bases de dados
Marcelo - MK Softwares
marcelo em mksoftwares.com.br
Quinta Junho 18 10:37:23 -03 2020
Obrigado perlo retorno Sandro
Respondendo as suas perguntas:
-Como é a arquitetura que você utiliza?
Hoje a necessidade para essa função seria para supermercados e lojas de
roupas, mas atendemos vários segmentos, menos farmácias e postos de
gasolina.
- Existe uma unidade matriz com uma base de dados própria?
No momento são existe uma matriz propriamente dita, mas se for implantar
esse cenário, ja pensei que terá que ser implantado uma matriz.
- Cada loja (filial) tem a sua base de dados própria que deve ser
sincronizada com a base da matriz?
Sim hoje cada empresa tem uma base de dados local.
- Dentro de cada loja, os PDVs usam uma base local própria que deve ser
sincronizada com a base da loja?
Sim os pdvs acessam uma base de dados localmente. O PDVs não tem uma
base local, todos trabalham acessando o banco de dados na rede local.
Você poderia fornecer mais detalhes?
Veja se esta bem explicado, tenteni expor o máximo possivel do cenário.
Em 18/06/2020 09:28, Sandro Souza escreveu:
> Bom dia/tarde/noite meu nobre.
>
> Cada PDV está acessando uma base de dados local ou todos estão
> acessando a mesma base do servidor?
>
> Veja o meu cenário e compare com o seu para verificar se algo pode ser
> aproveitado.
>
> Trabalho em uma holding (conjunto de empresas), e nesse caso, um grupo
> de distribuidoras de medicamentos farmacêuticos, com uma unidade
> matriz e umas 10 unidades filiais atualmente.
>
> Inicialmente, a base de dados, em Oracle, fica na matriz, e as filiais
> apenas acessam o sistema via terminal service (área de trabalho
> remota) via link dedicado.
>
> O que fiz foi o seguinte: Vi as partes do sistema legado que mais são
> utilizadas nas filiais, e criei uma base, em Firebird 2.5, contendo
> apenas as tabelas que são utilizadas por essas primeiras partes.
>
> Para sincronizar tudo, acrescentei uma coluna de alteração tanto nas
> tabelas da base principal Oracle como nas mesmas tabelas na base em
> Firebird.
>
> Essa coluna que funciona como flag de alteração é do tipo TIMESTAMP e
> opcional (não é NOT NULL), pois não adiantaria apenas marcar o
> registro como "alterado ou não" (um CHAR(1) contendo S ou N, por
> exemplo), pois enquanto um registro alterado fosse copiado de uma base
> para a outra, ele poderia sofrer uma nova alteração, e sendo assim, ao
> terminar de copiar a primeira versão do registro, e alterar o valor
> dessa coluna para N, eu perderia as outras possíveis alterações.
>
> Deixando essa coluna como TIMESTAMP, eu salvo o momento da inserção ou
> alteração do registro.
>
> Para garantir isso, e ficar de forma transparente para o sistema
> legado, criei triggers/gatilhos para cada uma das tabelas a serem
> sincronizadas.
>
> Essas triggers salvam o valor de CURRENT_TIMESTAMP nessa coluna de
> "registro alterado".
>
> Se a coluna está vazia (NULL) significa que o registro não precisa ser
> sincronizado, então eu pesquiso apenas por registros onde essa coluna
> IS NOT NULL.
>
> Uma vez que o programa de sincronização de dados copia esse registro
> de uma base para outra, ele faz um UPDATE naquele registro, passando
> os valores da chave primária (é claro), mas também com a condição de
> que a coluna de "registro alterado" tenha aquela data e hora lidos
> inicialmente, ou seja, se essa coluna tinha o valor "2020-06-18
> 10-01-23.456", e durante a copia do registro, o registro foi novamente
> alterado, significa que agora essa mesma coluna já está com um outro
> valor de data e hora, e sendo assim, quando executar o UPDATE TABELA_X
> SET REGISTRO_ALTERADO = NULL WHERE (CHAVE_PRIMARIA =
> valor-da-chave-primária) AND (REGISTRO_ALTERADO = '2020-06-18
> 10-01-23.456'), significa que só vai limpar (NULL) a coluna de
> "registro alterado" se não houve qualquer nova alteração nesse
> registro durante a cópia.
>
> Se houve alguma alteração, o UPDATE não apagará o valor da coluna, por
> conta dessa última condição, e dessa forma, eu não perco possíveis
> novas alterações.
>
> No meu caso, a sincronização é sempre no duplo sentido, ou seja, do
> Oracle para o Firebird e vice versa.
>
> Essa base em Firebird foi copiada para cada uma das filiais.
>
> No meu caso, o código da filial está incluído nos registros que são
> tratados individualmente nas próprias filiais (o sistema legado já
> nasceu assim).
>
> Por exemplo, o cadastro de produtos é único e global, todas as filiais
> acessam, mas só a matriz pode incluir, alterar ou excluir. As filiais
> podem apenas consultar.
>
> No caso dos estoques dos produtos, são individuais por filial, então a
> tabela de dados de produto por filial contém todas as informações do
> produto que são referente àquela filial (saldo em estoque, preço de
> compra, preço de venda, etc...).
>
> Devido a essa arquitetura do sistema legado, não tive necessidade de
> criar uma coluna separada de "registro alterado" para cada uma das
> filiais, já que cada filial só alterará os registros referentes a ela
> mesma (com o código da filial correspondente no próprio registro),
> então não há choque de informações.
>
> O programa de sincronização de dados que eu desenvolvi funciona dentro
> da matriz, e conecta com cada uma das bases Firebirds de cada uma das
> filiais, fazendo tudo acontecer de forma organizada, inclusive com
> tolerância a quedas de conexão.
>
> Como é a arquitetura que você utiliza?
>
> Existe uma unidade matriz com uma base de dados própria?
>
> Cada loja (filial) tem a sua base de dados própria que deve ser
> sincronizada com a base da matriz?
>
> Dentro de cada loja, os PDVs usam uma base local própria que deve ser
> sincronizada com a base da loja?
>
> Você poderia fornecer mais detalhes?
>
> Espero ter mais ajudado que atrapalhado. :D
>
>
> Em qua., 17 de jun. de 2020 às 21:49, Marcelo - MK Softwares
> <marcelo em mksoftwares.com.br <mailto:marcelo em mksoftwares.com.br>> escreveu:
>
> Pessoal boa noite
>
> Como fazer a sincronização de bases de dados. Cenário:
>
> - Um servidor sofrendo alterações diversas em seus registros, e um ou
> vários PDVs vendendo na loja, isso em rede local;
>
> - Um servidor sofrendo alterações diversas em seus registros, e as
> outras filiais vendendo.
>
> Até imagino que a cada registro alterado o mesmo poderia ter uma
> flag de
> alteração e os "clients" usariam essa flag para localizar os
> registros
> alterados e sincronizar. Mas no caso dos PDVs, onde pode ser um ou
> vários, uma flag não bastaria, teria que ter uma flag para cada
> pdv, e
> se tiver 30 pdvs na loja, terei 30 flags no banco.
>
> Hoje uso linguagem C# desenvolvendo aplicações desktop.
>
> Se alguém puder dar alguma sugestão agradeço.
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br <http://www.firebase.com.br>) -
> Hospedado em www.locador.com.br <http://www.locador.com.br>
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>
Mais detalhes sobre a lista de discussão lista