Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

blockmonork

[Resolvido] criar view entre 2 bancos em servidores diferentes

Recommended Posts

Prezados, não consegui encontrar através da busca do site algo relativo à minha dúvida. Caso já exista algo similar, favor me enviar o link e peço desculpas.

 

Meu caso é o seguinte: Tenho 4 tabelas em 2 bancos de dados separados (cada banco está num servidor fisicamente separado) e preciso sincronizar essas 4 tabelas, que são idênticas, ou seja, preciso replicar de um banco para o outro.

 

Porém, a sincronia deve ser feita do banco que sofreu a alteração para o que não sofreu, e isso pode ser do server1 para o server2 ou o contrario, caso server2 tenha sido modificado, este é que realizará a alteração em server1.

 

Eu não poderia fazer da forma "gambiarra" (pesquisando banco1.tabela onde banco1.tabela.campo != banco2.tabela.campo) pois isso pesaria os 2 servidores, pois um deles está na web e tenho tabelas com +- 300mil registros!

 

Pensei em fazer isso com uma view.

 

Será que é uma boa alteranativa?

 

Caso a view seja a alternativa, como eu poderia passar essa sql-view para o php?

 

Desde já agradeço pela atenção!

Compartilhar este post


Link para o post
Compartilhar em outros sites

Então, Andrey. Obrigado pela informação. Mas eu já tinha pensado em usar arrays mas o código vai ficar muito pesado.

As tabelas tem muitos campos (algumas com mais de 30!) e de qualquer forma eu teria puxar todos os dados das 2 tabelas para depois fazer essa verificação nos arrays. Ai imagina dois arrays cada um com 30 campos e com milhares de registros?!

 

Será que alguém pode me dizer se replicação entre bancos resolveria? Pois pelo que já li (nunca fiz isso) pra replicar, é preciso ter um server master e os slaves, mas o problema é que não há um master e um slave, pois os dois atualizarão um ao outro.

 

Tá meio complicado esse problema, pois é um banco de dados local (o banco fica na loja do cliente onde roda um programa local que usa o banco) e um banco de dados do site dele cliente (loja virtual).

 

E ele não quer usar o sistema local dele puxando da web e nem que a web puxe o banco local!!! Pois em ambos os casos o sistema vai ficar lento.

 

Quando o site vender, deve atualizar o banco local e quando a loja física dele vender, deve atualizar o banco do site (por causa do estoque).

 

Do site pra loja eu criei uma tabela temporária que salva as informações que preciso para atualizar na loja, aí tá tranquilo. Eu tinha pensado em criar um script php em que o delphi (que é o programa local dele) chamasse para enviar as alterações, ai ele funcionaria igual tá no site, mas na loja eu não tenho como fazer isso, pois ele disse que as alterações no estoque ocorrem em várias partes do programa.

 

 

Será que alguém consegue me dar uma luz de como resolver isso?

 

 

Obrigado.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Caso possua privilégios administrativos, para alterar arquivos de configuração e reiniciar os serviços, você pode optar por replicação de dados.

 

Como você esta de referindo a apenas 2 tabelas, a solução de dados federados me parece mais adequada.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Como você esta de referindo a apenas 2 tabelas, a solução de dados federados me parece mais adequada.

 

Eu também acho .. afinal, ele só insere em um banco de dados, as outras tabelas são consideradas links para o banco original.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Obrigado a todos pelas informações.

Prog, vou ler com calma sobre federated tables...

 

Mas na verdade não são apenas 2 tabelas, no meu último post fiz referência à duas tabelas para simplificar a história.

 

São ao todo quatro tabelas (cliente, produto, venda, venda_itens) em dois servers, sendo que dessas 4, 3 (exceto cliente) serão alteradas com mais frequência, pois sempre que houver uma venda no site ou na loja, as tabelas são alteradas, (a tabela produto terá o estoque alterado e as tabs venda e venda_itens consequentemente terão um insert referente à venda) podendo inclusive na loja física surgir novos produtos (que seria um comando insert na tab.produto para o banco da web)

 

:)

 

É como diz o ditado: "Quanto mais mexe, mais fede" - pois a estrutura geral do banco é bem complicada e mal modelada, com infinindáveis e redundantes campos, mas enfim.

 

Obrigado pelas dicas e assim que eu rodar uns testes, postarei aqui. Em breve!

Compartilhar este post


Link para o post
Compartilhar em outros sites

Prezados,

 

Após analisar a opção de usar a tabela federada, acho que não vai resolver o meu caso, pois eu não preciso ter uma tabela como espelho de outra, e sim que ambas as tabelas (todas as quatro) sejam idênticas, mesmo estando em locais diferentes.

 

Se eu usar o site como federated para puxar dados da loja, o site ficará muito lento (fiz um teste e levou 2 segundos para puxar 5000 registros de uma tabela...e como eu disse no post inicial, tenho tabelas com mais de 100 mil registros) e vice versa (da loja para o site também ficará lento).

 

Tentei usar o federated em conjunto com a tabela física entre localhost(federated) e física(web server) e não deu certo!

 

Será que fiz algo errado? pois usei a lógica de "pesquisar tudo entre federated,local onde fed.estoque != local.estoque" e me retornar a linha.

 

O sistema entrou em loop! rs! foi KH da minha?

 

 

Ainda não sei o que fazer...Vou manter o sistema usado no site (grava somente as alterações numa tabela temporária e atualiza as tabelas da loja conforme os dados) e da parte da loja para o site, estou pensando em mandar um drop table geral e copiar todos os dados novamente!

 

Essa seria a alteranativa do desesperado pois o banco tem +- 200MB!!!

 

Não estou conseguindo enxergar uma solução para o caso loja => site.

 

O problema é que não tem como o sistema saber se teve ou qual(is) campo(s) foi(ram) alterado(s) nas tabelas da loja e que ainda não foram no site.

 

Se fosse somente insert seria bem mais fácil, mas produto vai ter update no estoque diariamente, e eu não encontrei meio de verificar isso a não ser confrontando todos os registros entre as duas tabelas. Então entre cruzar dados de 2 tabelas(ou que seja popular um array para o webserver) e apagar uma e recriá-la, eu escolhi a segunda opção.

 

O que vocês acham? Será que não consegui enxergar no federated o potencial para resolver isso? ou teria uma outra solução?

 

Agradeço a paciência e colaboração de todos.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Pois é!

 

Não estou conseguindo ver solução pra isso...

 

Vou tentar ver com o cliente se conseguimos configurar o server do provedor dele pra aceitar replicação dos bancos.

 

Se alguém ainda souber de uma forma de se fazer isso...aceito sugestões! TODAS!

 

Obrigado.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Para saber somente os registros que sofreram alteração, na tabela estoque (por exemplo), crie uma coluna do tipo timestamp, este tipo de coluna pode ser parametrizado para atualizar sempre que criar um novo registro ou a cada update, desta forma você sempre saberá quando foi a última modificação do registro. Você também vai precisar de uma tabela de controle, apenas para saber quando foi realizada a última "sincronização". Pelo que entendo de tabelas federadas, é possível criar uma tabela federada local a partir de uma view remota. Talvez esta estratégia resolva a sua questão.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Resolvi o problema da forma mais simples possível!

 

Criando triggers que salvam somente os dados que me interessam das modificações na tabela sincronia - que já existe mas eu estava tão bitolado numa ideia que não estava sabendo como preenchê-la!

 

Obrigado a todos pela paciência e atenção!

 

Pode dar o tópico por resolvido.

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.