REPLICACAO DE DADOS ENTRE DBS
Bom dia!
Tenho um programa VB6 que acessa um DB access. O programa foi feito para uma rede local, mas agora o cliente que que ele funcione em várias unidades diferentes, mas tudo centralizado na matriz.
Pensei então implementar na estrutura do DB uma forma de identificar a unidade e criar duas rotinas (uma nas unidades para exportar todos os registros incluidos, excluÃÂÂdos e alterados desde a última exportação de dados, para um DB limpo com a mesma estrutura do principal) Este DB com os dados seria enviado por email ou CD para matriz que teria uma segunda rotina para importar os dados para o banco centralizado.
Essa seria a sistemática para migrar os dados de cada unidade para matriz. Até aqui acho que não teria muito problema.
Pergunta:
Como eu deveria ajustar o DB para que isso funcionasse corretamente?
Hoje cada tabela do DB tem um ÃÂÂndice único, então como deveria fazer para conseguir migrar os dados e na hora de importar para o bd único não ter problemas e identificar corretamente os registros de cada unidade?
Nota: Esse programa faz um controle de estoques através de Saldos Parciais, com uma tabela auxiliar, ou seja, a cada lançamento é criado o material, data e tipo de movimentação, entrada, saida. No final do dia é executada uma rotina que contabiliza todos os lançamentos ajustando o saldo de cada material por almoxarifado, pois tambám são vários.
Tenho um programa VB6 que acessa um DB access. O programa foi feito para uma rede local, mas agora o cliente que que ele funcione em várias unidades diferentes, mas tudo centralizado na matriz.
Pensei então implementar na estrutura do DB uma forma de identificar a unidade e criar duas rotinas (uma nas unidades para exportar todos os registros incluidos, excluÃÂÂdos e alterados desde a última exportação de dados, para um DB limpo com a mesma estrutura do principal) Este DB com os dados seria enviado por email ou CD para matriz que teria uma segunda rotina para importar os dados para o banco centralizado.
Essa seria a sistemática para migrar os dados de cada unidade para matriz. Até aqui acho que não teria muito problema.
Pergunta:
Como eu deveria ajustar o DB para que isso funcionasse corretamente?
Hoje cada tabela do DB tem um ÃÂÂndice único, então como deveria fazer para conseguir migrar os dados e na hora de importar para o bd único não ter problemas e identificar corretamente os registros de cada unidade?
Nota: Esse programa faz um controle de estoques através de Saldos Parciais, com uma tabela auxiliar, ou seja, a cada lançamento é criado o material, data e tipo de movimentação, entrada, saida. No final do dia é executada uma rotina que contabiliza todos os lançamentos ajustando o saldo de cada material por almoxarifado, pois tambám são vários.
Agora ... pensando em toda essa mão de obra que vc vai ter, será que não seria mais interessante migrar pra um SQL Server com um banco de dados centralizado e as filiais acessando esse banco SQL via internet ?
Assim vc teria um banco de dados SQL centralizado, com todas as infos somente num unico local, sem precisar se preocupar com isso tudo ai em cima.
Pelo que imagino as filiais ja tem acesso a internet, portanto seria uma questão somente de centralização.
Qualquer coisa posta ai de novo.
Flws
Assim vc teria um banco de dados SQL centralizado, com todas as infos somente num unico local, sem precisar se preocupar com isso tudo ai em cima.
Pelo que imagino as filiais ja tem acesso a internet, portanto seria uma questão somente de centralização.
Qualquer coisa posta ai de novo.
Flws
Olha, concordo com o Victor.
Seu trabalho para migrar para SQL Server seria bem menor do que todas estas rotinas de exportação e importação.
Porém a modelagem do seu banco de dados creio que continue precisando de uma adaptação, talvez seja interessante saber de qual unidade veio determinada informação.
Mas aàfica fácil, se seu sistema tiver um controle de acesso (Usuários e Senhas), basta vc relacionar os usuários com Unidades (Teria que ter um cadastro de unidades), desta forma vc tem todo o controle.
Agora se vc realmente optar por essa prática de exportação e importação, creio que cada unidade deve ter uma espécie de ID, e aquelas tabelas principais, devem possuir um campo (Chave Estrangeira) para o ID da unidade.
A idéia básica creio que seja esta.
Seu trabalho para migrar para SQL Server seria bem menor do que todas estas rotinas de exportação e importação.
Porém a modelagem do seu banco de dados creio que continue precisando de uma adaptação, talvez seja interessante saber de qual unidade veio determinada informação.
Mas aàfica fácil, se seu sistema tiver um controle de acesso (Usuários e Senhas), basta vc relacionar os usuários com Unidades (Teria que ter um cadastro de unidades), desta forma vc tem todo o controle.
Agora se vc realmente optar por essa prática de exportação e importação, creio que cada unidade deve ter uma espécie de ID, e aquelas tabelas principais, devem possuir um campo (Chave Estrangeira) para o ID da unidade.
A idéia básica creio que seja esta.
Marcelo e Victor, tem razão.....Tbem Concordo com eles
Tem muitas opções para vc utilizar.......
MySql, FireBird, Sql, entre outros ae pelo mercado........
Tem muitas opções para vc utilizar.......
MySql, FireBird, Sql, entre outros ae pelo mercado........
Bem amigos o problema é o investimento para isso, o cliente não quer um SQL para isso, além do que algumas filiais não tem acesso a Web, bem como o local que será centralizado o banco não fica no ar 24 horas, além de não ter estrutura para um servidor desses.
Se fosse para ter isso Web, então meu sistema não teria sentido e partiriam para um site o que também foi descartado. Por isso perguntei, já que meu sistema está pronto e teria de ajustar para essas exigências.
Sei que o trabalho não será fácil, mas o caminho é esse mesmo.
Se fosse para ter isso Web, então meu sistema não teria sentido e partiriam para um site o que também foi descartado. Por isso perguntei, já que meu sistema está pronto e teria de ajustar para essas exigências.
Sei que o trabalho não será fácil, mas o caminho é esse mesmo.
Luis estou desenvolvendo algo semelhante ao seu sistema.Só que estou usando como banco de dados Firebird.
Nas filiais:
Todos os registros tem um campo que marca se foi exportado (S/N) e outro que marca a data/hora da exportação.
Se é feito um novo registro, o campo exportado é gravado logicamente como N.
Caso o registro (que já foi exportado) seja editado, ao salva-lo volto o campo exportado como N.
Se um registro (que ja foi exportado) for excluÃÂÂdo, gravo o id dele em uma tabela a parte (exemplo: tbl_clie_deletados).
Gero um arquivo de texto (criptografado e com a extensão renomeada) para cada tabela, depois pego todos esses arquivos e gero um arquivo compactado.
Na matriz:
cada registro tem uma chave composta: cnpj filial + idregistro (o mesmo usado na filial - numeracao não automatica).
Na importação analizo se o registro eÂÂ' novo: insert, se for atualização: update e por ultimo verifico as tabelas de exclusão.
O esquema é + ou - esse.
Abs
Nas filiais:
Todos os registros tem um campo que marca se foi exportado (S/N) e outro que marca a data/hora da exportação.
Se é feito um novo registro, o campo exportado é gravado logicamente como N.
Caso o registro (que já foi exportado) seja editado, ao salva-lo volto o campo exportado como N.
Se um registro (que ja foi exportado) for excluÃÂÂdo, gravo o id dele em uma tabela a parte (exemplo: tbl_clie_deletados).
Gero um arquivo de texto (criptografado e com a extensão renomeada) para cada tabela, depois pego todos esses arquivos e gero um arquivo compactado.
Na matriz:
cada registro tem uma chave composta: cnpj filial + idregistro (o mesmo usado na filial - numeracao não automatica).
Na importação analizo se o registro eÂÂ' novo: insert, se for atualização: update e por ultimo verifico as tabelas de exclusão.
O esquema é + ou - esse.
Abs
OI Luiz,
Ja tenho algo semelhante no meu sistema, criei um tabela contendo quais itens eu tenho que replicar, no meu caso eu tenho um banco de dados nacional de onde partem as alteração básicas tipo tabela de produtos, valores, etc. que envio para a INTERNET nos bancos locais de cada estado.
A partir dai um aplicativo verifica esta mesma tabela temporaria para efetuar a atualização no banco de dados dos meus distibuidores / lojistas
Como utilizo SQL fica facil gravar as alterações necessárias nesta tabela temporaria, inclusão, exclusão alterações são todas tratadas via trigger.
A estrutura da tabela temporaria eé bem simples:
Chave - Mantenho string para pesquisa no BD
Tabela - qual a tabela que a operação será realizada
Operacao - tipo de operação (I - Inclusão, E - Exclusão, U - Alteração)
CNPJ - cnpj da distribuidora ou loja que proveu o registro
Data - data da operação
Situacao - flag indicando se ja foi processado ou não.
uma linha tipia desta tabela seria
Chave Tabela Operacao Data Situação
=============================================== =========== ======== =================== ======
CodigoPedido="8408" AND CodigoProduto="8449206" LinhaPedido I 2007-08-20 11:35:07 ABERTA
CodigoProduto="211973" Valores U 2007-08-20 11:39:12 ABERTA
com isso consigo saber o que sofreu alguma alteração nas minhas filiais / matriz replicando toda a linha de registro das tabelas quando necessário.
no meu caso o processo é todo on-line sendo executado de tempos em tempos, acho que não terá dificultado em transformar essa idéia para a sua necessidade.
como disse o Ricardo, tambem mantenho o controle de quem gerou os registros pelo CNPJ da empresa com resalva que uso tambem uma tabela auxiliar com dados básicos sobre todas as lojas da rede que dou suporte para poder tirar relatórios do tipo qual produto é mais vendido em determinada região do pais.
Ja tenho algo semelhante no meu sistema, criei um tabela contendo quais itens eu tenho que replicar, no meu caso eu tenho um banco de dados nacional de onde partem as alteração básicas tipo tabela de produtos, valores, etc. que envio para a INTERNET nos bancos locais de cada estado.
A partir dai um aplicativo verifica esta mesma tabela temporaria para efetuar a atualização no banco de dados dos meus distibuidores / lojistas
Como utilizo SQL fica facil gravar as alterações necessárias nesta tabela temporaria, inclusão, exclusão alterações são todas tratadas via trigger.
A estrutura da tabela temporaria eé bem simples:
Chave - Mantenho string para pesquisa no BD
Tabela - qual a tabela que a operação será realizada
Operacao - tipo de operação (I - Inclusão, E - Exclusão, U - Alteração)
CNPJ - cnpj da distribuidora ou loja que proveu o registro
Data - data da operação
Situacao - flag indicando se ja foi processado ou não.
uma linha tipia desta tabela seria
Chave Tabela Operacao Data Situação
=============================================== =========== ======== =================== ======
CodigoPedido="8408" AND CodigoProduto="8449206" LinhaPedido I 2007-08-20 11:35:07 ABERTA
CodigoProduto="211973" Valores U 2007-08-20 11:39:12 ABERTA
com isso consigo saber o que sofreu alguma alteração nas minhas filiais / matriz replicando toda a linha de registro das tabelas quando necessário.
no meu caso o processo é todo on-line sendo executado de tempos em tempos, acho que não terá dificultado em transformar essa idéia para a sua necessidade.
como disse o Ricardo, tambem mantenho o controle de quem gerou os registros pelo CNPJ da empresa com resalva que uso tambem uma tabela auxiliar com dados básicos sobre todas as lojas da rede que dou suporte para poder tirar relatórios do tipo qual produto é mais vendido em determinada região do pais.
Valey Ricardo e Hernanni, vou analisar e fazer obrigado.
Tópico encerrado , respostas não são mais permitidas