Comments on: Múltiplas Fontes de Dados, uma Engine ORM http://philcalcado.com/2007/03/30/multiplas-fontes-de-dados-uma-engine-orm/ Software e Batatas Fri, 06 Jan 2012 20:39:16 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: pcalcado http://philcalcado.com/2007/03/30/multiplas-fontes-de-dados-uma-engine-orm/comment-page-1/#comment-33698 pcalcado Fri, 06 Apr 2007 15:56:53 +0000 http://fragmental.com.br/blog/?p=323#comment-33698 Então, Tiago, eu fiz na mão mesmo mas *realmente* gostaria de ter usado alguma ferramenta. O ganho de performande que me referi foi simplesmente não ir a um banco de dados onde tabelas são compartilhadas por zilhões de aplicações, cada uma com sua política e cache (quando o fazem). Realmente o problema maior aí é arquitetural mas é algo que tenho que conviver...ao menos por enquanto. Com certeza todo esse hype web2.0 vai me dar diversas oportunidades para testar isso. Neste momentou estou justamente imaginando como fazer uma aplicação (um serviço REST, na verdade) consultar ou um ou outro para casos de 'get by id'. Então, Tiago, eu fiz na mão mesmo mas *realmente* gostaria de ter usado alguma ferramenta. O ganho de performande que me referi foi simplesmente não ir a um banco de dados onde tabelas são compartilhadas por zilhões de aplicações, cada uma com sua política e cache (quando o fazem). Realmente o problema maior aí é arquitetural mas é algo que tenho que conviver…ao menos por enquanto.

Com certeza todo esse hype web2.0 vai me dar diversas oportunidades para testar isso. Neste momentou estou justamente imaginando como fazer uma aplicação (um serviço REST, na verdade) consultar ou um ou outro para casos de ‘get by id’.

]]> By: Tiago Silveira http://philcalcado.com/2007/03/30/multiplas-fontes-de-dados-uma-engine-orm/comment-page-1/#comment-33597 Tiago Silveira Fri, 06 Apr 2007 00:38:51 +0000 http://fragmental.com.br/blog/?p=323#comment-33597 Hmmm, gostei muito da sua observação. Mas não ficou muito claro se você chegou a usar o Hibernate Search. Entendi que vc fez isso na mão, salvando o ID do objeto no índice, carregando o objeto separadamente. O que é a forma mais elegante de fazer a coisa mesmo. Eu concordo contigo 100% quando você diz que evitar consultas ao banco é ótimo. Mas o Hibernate não carrega o objeto a partir do documento no índice, ele te dá um proxy comum e na hora da inicialização, ele faz um SELECT mesmo assim. Portanto, a menos que a busca full-text substitua uma query muito, muito complexa, não acredito que haja qualquer ganho de performance. Também não vejo ganho em termos de uso de memória, pelo contrário. Sobra o ganho no tempo de desenvolvimento, que também não me convenceu. Enfim, assim que eu souber como fazer, eu posto de novo sobre o assunto. A minha curiosidade maior no momento é: será que essa arquitetura cobre os 80% dos casos "fáceis"? Hmmm, gostei muito da sua observação. Mas não ficou muito claro se você chegou a usar o Hibernate Search. Entendi que vc fez isso na mão, salvando o ID do objeto no índice, carregando o objeto separadamente.

O que é a forma mais elegante de fazer a coisa mesmo. Eu concordo contigo 100% quando você diz que evitar consultas ao banco é ótimo. Mas o Hibernate não carrega o objeto a partir do documento no índice, ele te dá um proxy comum e na hora da inicialização, ele faz um SELECT mesmo assim. Portanto, a menos que a busca full-text substitua uma query muito, muito complexa, não acredito que haja qualquer ganho de performance. Também não vejo ganho em termos de uso de memória, pelo contrário. Sobra o ganho no tempo de desenvolvimento, que também não me convenceu.

Enfim, assim que eu souber como fazer, eu posto de novo sobre o assunto.

A minha curiosidade maior no momento é: será que essa arquitetura cobre os 80% dos casos “fáceis”?

]]>