O melhor é compartilhar. Use webservices (se possível restful). Mas ficar com bases repetidas separadas é foda, porque a sincronização delas acaba sendo mais difícil que a replicação.
Mas, no caso de tabelas pequenas que sofrem poucas alterações (ex: lista de estados e capitais), replicá-las é mais apropriado para economizar a rede.
[quote=victorwss]O melhor é compartilhar. Use webservices (se possível restful). Mas ficar com bases repetidas separadas é foda, porque a sincronização delas acaba sendo mais difícil que a replicação.
Mas, no caso de tabelas pequenas que sofrem poucas alterações (ex: lista de estados e capitais), replicá-las é mais apropriado para economizar a rede.[/quote]
Acho uma pessima ideia compartilha-las. Quem dita o contexto de cada tabela é cada sistema em particular. Se os sitemas sao diferentes faze-los utilizar o mesmo recurso irao acopla-los dificultando a evolucao de cada um de forma independente. Voce esta sugerindo um modelo de web service anemico!
Minha tendencia é imaginar banco de dados como detalhe de implementacao. Integracao entre eles via webservices mas cada sistema possui sua responsabilidade definida.
Na minha opnião vcs poderiam adotar SOA - Onde criariam serviços e diponibilizariam esses serviços conforme a necessidade de cada um assim vc não precisa colocar a base inteira para outro estado acessar.Mas simplismente uma pequena parte do seu negocio.
Agora no caso de base de Dados difirentes tem que ser estudado direito se as tabelas forem iguais e banco for estremamente grande então é melhor deixar separados se não ,não faz sentido deixar separada a base de dados.
Pelo que entendi pra esse cenário é mais indicado uma replicação, acessar a uma única tabela com vários bancos traria algumas consequência do tipo:
1º Pelo menos onde eu trabalhei com banco de dados federados, o pessoal da segurança nos torrava a paciência, pois tinhamos que liberar grant´s a pro usuários shadow em algumas de nossas tabelas.
2º É o seu sistema cair e vc vai os analistas do outro sistema vindo te torrar a paciência e como o amigo disse, vc torna seu sistema totalmente dependente do outro.
3º Como foi dito Overhead, sem contar aqueles possiveis tablescan q vc pode herdar das outras aplicações.
Eu acredito que é complexidade demais pra pouco ganho!
Acho que ficar replicando dados é no geral uma idéia ruim. Se você não quer que múltiplos sistemas acessem o mesmo banco de dados, então faça com que apenas um acesse e os demais solicitem a este via webservices (ou sockets, ou RMI ou EJB ou qualquer outra coisa).
Isso é problema em qualquer sistema que usa banco de dados, não é exclusividade dele.
A não ser que tenham uma finalidade muito específica, múltiplos bancos só dão dor de cabeça. Evite quando puder.[/quote]
Bruno,
o que vc disse vai contra tudo o que se tem falado sobre integração por serviços (SOA). Sistemas/processos/negócios devem ser integrados por serviços (sejam eles WS, REST, HTTP, JMS, socket, etc,etc) e NÃO pelo banco. Uma abordagem onde cada serviço possui seu banco é a mais recomendável.
Isso é problema em qualquer sistema que usa banco de dados, não é exclusividade dele.
A não ser que tenham uma finalidade muito específica, múltiplos bancos só dão dor de cabeça. Evite quando puder.[/quote]
Bruno,
o que vc disse vai contra tudo o que se tem falado sobre integração por serviços (SOA). Sistemas/processos/negócios devem ser integrados por serviços (sejam eles WS, REST, HTTP, JMS, socket, etc,etc) e NÃO pelo banco. Uma abordagem onde cada serviço possui seu banco é a mais recomendável.[/quote]
Me referi ao post original. Um sistema acessando diretamente vários SGBDs diferentes, com tabelas iguais(replicadas?) que servem a mesma finalidade, é dor de cabeça.
Agora cada serviço ter seu próprio banco é perfeitamente normal, desde que este tenha somente uma única responsabilidade dentro do sistema.
[quote=java_coffe]O negocio é que apesar de cada sistema ter seu banco de dados existe tabelas que armazenam as mesma informações , nesse caso vai existir replicações.
Eu não imagino que usando webservice va resolver os problemas , primeiramente que vai cair de mais a perfomance . Imagine um consulta onde vai haver um inner join entre a tabela do sistema A que vai fazer uma consulta no Sistema B onde esta as informações verdadeiras pra nao haver replicação…com web service não creio que vá ser tao legal assim !!!
[/quote]
É óbvio que, caso vc não tenha seus serviços bem modelados, simplesmente expô-los por WS só piorará a situação. Talvez vcs precisem da ajuda de um profissional para remodelar seus serviços. Vc não vai encontrar respostas sobre como fazer isso em um fórum.
Bom, adotar uma arquitetura SOA traria muitos beneficios pra empresa e com certeza problemas como esse de redundância seriam resolvidos, mas se não há budget e nem interesse na equipe em investir em um projeto de grande porte, não vale a pena nem pensar num WS pra esse probleminha.
Tenho tabelas de cadastro de pessoas que são utilizadas por quase todos os sistemas (dezenas deles) daqui, ou seja, são integrados pelo banco.
Num caso de um volume de consultas muito grande(na casa das dezenas de milhares por minuto), que vantagens teria os WS, considerando um cluster de servidores? Trafegar os dados pela rede não tem um impacto grande na performance?
O negocio é que apesar de cada sistema ter seu banco de dados existe tabelas que armazenam as mesma informações , nesse caso vai existir replicações.
Eu não imagino que usando webservice va resolver os problemas , primeiramente que vai cair de mais a perfomance . Imagine um consulta onde vai haver um inner join entre a tabela do sistema A que vai fazer uma consulta no Sistema B onde esta as informações verdadeiras pra nao haver replicação…com web service não creio que vá ser tao legal assim !!!