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.
