Tratamento das informação na sua origem ORM

This message was edited 8 times. Last update was at 15/02/2009 02:07:14

Pessoal, estou desenvolvendo um novo sistema, definindo a arquitetura lógica.. ect.

O fato:
Segundo o texto http://pt.wikipedia.org/wiki/SQL, que nos dá um visão histórico SQL, podemos afirmar hoje: SQL não é padrão! A gerra entre fornecedores de DB acabou com com o trabalho do ANSI.

A Oracle incluiu a "vantagem", do uso de linguagens como Java no banco, e Postgres incluiu Pearl, C, TCl. Um nicho usa isso e ainda estou tentando descobrir quem.

Hoje temos ferramentas que considero a palmatória para para os fornecedores de DB, por exemplo Hibernate, dando liberdade as aplicações.

Mas existe um detalhe importande que faz uma grande diferênça (como sempre):

Eu não quero alagar a rede a trafegar informação burra entre a aplicação e o servidor de BD para simplismente fazer uma operação que pode ser feita pelo DB.

Na época de aplicações Client Server, as soluções: Stored Procedure e Triggers também foram criadas no intuito de amenizar a saída de dados desnecessária.

1: Compensa fingir que vamos trocar de DB a qualquer momento (ainda mais web) e não aplicar código PL-SQL ou T-SQL.. no DB?
2: Como resolver o problema do tratamento das informação na sua origem, sem perder o benefício de independência de banco?

Acredito que colocar a aplicação nos mesmo servidor do DB poderia amenizar, mas isso não é uma boa prática, certo?
Uma outra possível solução seria colocar somente minha camada de persistência, regras de négocio e DB no mesmo servidor, como?

Quanto ao uso de ferramentas no contexto: mapeamento, eu não tenho dúvida que existem vantagens.

Remendo do Remendo, voltando as origens.

JavaTeenager Membro desde: 02/10/2007 10:56:53 Mensagens: 162 Offline

F?io Henrique wrote:
1: Compensa fingir que vamos trocar de DB a qualquer momento (ainda mais web) e não aplicar código PL-SQL ou T-SQL.. no DB?
2: Como resolver o problema do tratamento das informação na sua origem, sem perder o benefício de independência de banco? Qual?

Já viu como isso cresce. Fica muito difícil manter isso depois fora que o reaproveitamento de uma SP geralmente e baixo, visto que alterações podem impactar em outras aplicações.
Não existe somente independencia de SGDB como benefício.

This message was edited 5 times. Last update was at 15/02/2009 11:26:25

Eu uso Hibernate JPA. As vantagens são fantásticas, eu sei. Mas estou estudando uma solução para trafego entre os servidores.
A quantidade de stored procedures em um banco varia de acordo com o desenvolvedor. Se ele sabe o que é uma View, Function, Trigger, Constraint, ele vai utilizar isso da maneira correta: criar e usar uma procedure quando necessário.

Notícias, artigos e o maior fórum brasileiro sobre Java