Sobre ORM

Hibernate tem um preço caro: Footprint, Proxies, e, não necessariamente todos os idiomas de SQL são suportados.

Repare que falo idioma, e não dialeto. É uma distinção sutil, mas convém explicar: Independente da forma normal, eu posso ter outras estratégias que convenham para racionalizar meu acesso aos dados. E estas sim, são idiosincráticas, como:
- Funções que Retornem Tabelas
- Consultas SQL que retornem mais de uma tabela
- Cursores SQL no Client ou Server-Side
- Funções que Criem Registros
- Stored Procedures (que não são funções) que façam outras mágicas
- Views que substituem tabela

E por aí vai. Óbvio que o ideal é você fazer com que a sua camada de dados evolua junto com o SQL, mas não necessariamente isto acontece. Em particular, no caso de sistemas legados, existe uma tendência muito grande a pegar-mos aquele sistemeeenha Access aonde a Normalização foi algo que foi algo que o Analista se lembra que foi dado, mas que faltou aquela aula. Basta ver o WorseThanFailure. :)

Repare que falo idioma, e não dialeto. É uma distinção sutil, mas convém explicar: Independente da forma normal, eu posso ter outras estratégias que convenham para racionalizar meu acesso aos dados. E estas sim, são idiosincráticas, como:
- Funções que Retornem Tabelas
- Consultas SQL que retornem mais de uma tabela
- Cursores SQL no Client ou Server-Side
- Funções que Criem Registros
- Stored Procedures (que não são funções) que façam outras mágicas
- Views que substituem tabela

Complementando :
-Redundancia de Dados;
-Normalização;
-Dependência funcional;
-Formas normais : 1º , 2º, 3º;
-Desnormalização;
È complicado quando se usa uma base de dados já pronta desde 19.. e tem que fazer funcionar aquela bagunça, então lembrei que posso mapear as minhas classes para um banco de dados relacional .:

Se você precisa acessar dados em um SGBD corporativo, utilize também estas técnicas. Não é porque seu sistema se comunica com este outro componente (o banco corporativo) via JDBC que ele é sua persistência. Utilizar um framework de ORM como Hibernate ou EJB 3.0 (JPA) é algo que eu não recomendaria porque o framework vai considerar que o banco de dados é sua persistência, não um outro sistema a ser integrado. EJB 3.0 por exemplo traz o mapeamento entre classes e tabelas para dentro dos seus arquivos-fonte, isto só é desejável se esta informação representa metadados do seu aplicativo, não configuração. Uma abordagem mais sadia mantendo a produtividade de um framework (afinal, ninguém gosta de escrever JDBC?) pode ser obtida utilizando frameworks ORM com propostas diferentes, como o iBatis.
http://blog.fragmental.com.br/2006/08/24/bases-de-dados-sao-recursos/

Será que temos que usar ORM em todos os casos, é claro que não, temos outros frameworks com iBATIS mais isso depende do nosso custo/benefício por estarmos usando um modelo OO para um mecanismo de banco de dados relacional.

Olá,

Acho muito difícil um cara saber OO e não saber modelagem de dados!
Se não modelar as classes direito não existe ORM que melhore a modelagem, ou seja, do mesmo jeito irá sair Endereço001 Endereço002 ... Endereço100!

Ahhh, e você reclama de 100 colunas em uma tabela?! Já peguei um sistema com 40 tabelas, só existia um campo que era chave primaria em todas, não existia relacionamento entre elas e tinha uma tabela com 645 campos!

Abraços!

WilliamSilva wrote:

Repare que falo idioma, e não dialeto. É uma Uma abordagem mais sadia mantendo a produtividade de um framework (afinal, ninguém gosta de escrever JDBC?) pode ser obtida utilizando frameworks ORM com propostas diferentes, como o iBatis.
http://blog.fragmental.com.br/2006/08/24/bases-de-dados-sao-recursos/

Será que temos que usar ORM em todos os casos, é claro que não, temos outros frameworks com iBATIS mais isso depende do nosso custo/benefício por estarmos usando um modelo OO para um mecanismo de banco de dados relacional.

Eu gosto do iBatis, mas mantendo um sistema que, entre os requisitos, ele precisa suportar vários backends, eu vi que ele é bom, mas não é perfeito.

Enfim, não existe a solução mágica. Cada um, cada um.

This message was edited 1 time. Last update was at 04/01/2008 16:03:13

Sei que o topico é bastante velho. Será apenas uma resposta para o thingol.
Rapaz, nao possuo curso superior e nem por isso crio tabelas de 100 campos e muito menos desconheço relacionamentos. Pelo contrario, procuro saber tudo sobre minha área de atuação, isso é importante pra mim.
Em contrapartida, vários dos muitos desenvolvedores que trabalhei junto, aqueles que "torraram" a cadeira da faculdade, são incapazes de escrever um sql script básico.

Achei sua citação preconceituosa. Não julgue a inteligência das pessoas pela quantidade de anos que ficaram "esquentado" bancos de faculdades. Um dos maiores programadores que conheci era Físico. Ah! Ele também nao criava tabelas de 100 campos.

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