Cheguei a conclusão de que o “sucesso” de ferramentas como o Hibernate se deve exclusivamente a incapacidade dos desenvolvedores de aprender modelagem de dados e SQL. O “sucesso” aí é relativo, me refiro a noção de que isso é necessário, não a quantidade de projetos mundo afora, pois, para dizer a verdade, não tenho visto muitos.
Uma boa parte dos desenvolvedores:
jamais ouviu falar de “formas normais”;
não sabe como e nem quando usar chave estrangeira;
quando conhece “chave estrangeira” ele não acredita na sua utilidade;
subquery, join, procedure, function…? Vixi. Aí você já está falando grego.
Assim qualquer coisa é difícil. Como escrever montes de XML pra mapping é mais fácil do que um simples comando SQL? Como adicionar dependência do seu projeto em um aplicativo de terceiros é mais fácil do que pegar um bean com os dados em uma única linha?
SQL é a melhor tecnologia que existe para esse tipo de manipulação de dados, criar uma forma “OO” é no mínimo reinventar a roda.
O pior são os que são contra “chave estrangeira”. É a mesma coisa que ser contra cinto de segurança.
Muita gente nem chegou a esquentar os bancos de alguma faculdade - e é por isso que você vê coisas bizarras como tabelas com 100 campos do tipo “endereco001”, “endereco002”, … “endereco099”, “endereco100” - isso porque o cara nem tem idéia de o que é um relacionamento.
Mas o Hibernate não é usado somente por quem não conhece nada de SQL. Acho legal o fato de não precisar reescrever queries, o aumento de produtividade, a independência do SGBD, etc. Tem ainda os casos de quem sabe mas não gosta de ficar escrevendo querie.
Ou você acha que um sujeito que não conhece normalização, join, etc vai conseguir fazer uma ORM boa?
IMHO para trabalhar com Hibernate acredito que conceitos de SQL são fundamentais, thiagosc. Se o cara não sabe isso ele é um programador ruim com ou sem hibernate.
[quote=felipec]Eu acho que o sucesso se deve a enorme improdutividade de se trabalhar com JDBC puro.
Não acho também que todos devam saber o que é uma Stored Procedure, um trigger e tal… mas…
não saber o que é chave estrangeira já é demais…[/quote]
Eu discordo um pouquinho… Na minha opinião TODOS os desenvolvedores deveriam sabem bem banco de dados relacionais. Há coisas ( e onde trabalho MUITAS coisas) que não são passíveis de serem manipuladas pelo hibernate, por exemplo. Tem que ser Stored Procedures, triggers e tal.
Os POG Certified só sabem fazer um tipo de select:
SELECT * FROM TABELA
Eventualmente, conheci alguns (utilizaram o mesmo código acima, em vários trechos) que estavam xingando a performance de uma base MySQL. Apenas pedi um EXPLAIN e criei um índice. E mandei eles procurarem entender como um RDBMS funcionava.
Lembrei que, em outro forum, um cara tentava criar uma tabela com o nome, por exemplo “João da Silva” e, nessa tabela, ele colocaria dados de um compra, por exemplo.
É claro que TODO MUNDO tentou faze-lo desistir dessa abordagem, inclusive eu me dei ao trabalho de mostrar uma forma de trabalhar com 3 tabelinhas, PK-FK, essas coisas, mas foi em vão.
Cheguei a conclusão q isso é programação na força bruta.
Eu gosto do JDBC puro. Pra questões de produtividade desenvolvi ferramentas próprias que geram meu código de acordo com a estrutura do banco, de modo que grande parte do acesso no JDBC ficam nas minhas classes base, fazendo que eu me preocupe pouco com código SQL (a não ser em relatórios). Ficou bem legal e rápido. O Hibernate estava meio lerdo na execução.
[quote=Thiagosc]Cheguei a conclusão de que o “sucesso” de ferramentas como o Hibernate se deve exclusivamente a incapacidade dos desenvolvedores de aprender modelagem de dados e SQL. O “sucesso” aí é relativo, me refiro a noção de que isso é necessário, não a quantidade de projetos mundo afora, pois, para dizer a verdade, não tenho visto muitos.
[/quote]
O sucesso de ferramentas como o hibernate está no fato delas proverem uma abstração OO para a persistência/recuperação de Objetos. Ou seja, ele usa objetos para persistir/recuperar objetos.
A beleza de usar uma linguagem OO como Java é que não é necessário saber essas coisas. Vc tem que entender que para quem usa OO o banco é apenas um sistema de arquivamento complexo e util para persistir e encontrar informação. Não é um ambiente de programação (logo, procedure e function são inuteis* ) , não é um sistema de validação de regras (logo trigger , chave estrangeira, referencia etc, são inuteis*) e não é um mecanismo formal. i.e. o objetivo é simplificar o mapeamento dos objetos para o banco e não do banco para os objetos; logo as formas normais são usada até onde forem uteis e join é uma coisa inútil*.
Inutil do ponto de vista da aplicação. Do ponto de vista estrutural de quem faz um framework de persistência, podem ser ferramentas importantes. O join pode ser usado, mas procudures e functions criam um vendor-lockin que é um problema muito grave do ponto de vista de quem escolher Java. Chave estrangeire/ referencias é bom até que começa a impedir o framework de persistencia de fazer as coisas da forma mais simples. Porque eu preciso integridade referencial explicita se o framework OO me garante essa integridade de forma implicita ? Pois é, não preciso.
Claro que posso usar , e às vezes é necessário usar os mecanismo do banco, mas 99%das vezes não é isso que desejamos fazer.
Esta é fácil. Porque o XML me garante que não vou ficar preso ao dialeto de determinado banco. Além de que o XML pode ser construido por ferramentas que se alimentam de outros dados, como diagrama ER.
Como adicionar ao seu projeto dependência de um banco de dados especifico é mais fácil do que pegar um bean com um objeto que abstrai o SQL e seus dialetos de forma automática?
Como fazer refactoring de objetos é mais dificil que fazer manipulação de strings SQL ?
SQL - Structured Query Language - é uma linguagem independente da tecnologia de banco. Tanto é que ela foi adaptada para objetos (HQL, EQL ,etc)
O que faz com que vc ache que SQL é só para banco de dados são os malditos dialetos criados pelos vendedores de RMDS. Ok, HQL tb é um dialecto maltido, mas o ponto é que SQL é independente e se adapta à tecnologia subjacente. Moral da historia, é possivel continuar usando SQL
de forma OO sem nunca saber que existe um banco de dados rodando.
E esta é que é a vantagem de OO: Encapsulamento.
Ué, usando Hibernate ou não, o desenvolvedor também tem que ter esses conceitos. O uso de uma ferramenta ORM não exclui a necessidade de conhecer chave estrangeira, join, etc.
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.
[quote] 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
[/quote]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 .:
[quote]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/[/quote]
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.
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!
[quote=WilliamSilva][quote] 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/[/quote]
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.
[/quote]
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.
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.
