Em boa parte dos casos o hibernate é até mais rapido que consultas feitas diretamente em sql.
"
[quote=marcosalex]Quando Hibernate não dá perda de performance, tudo bem. Isso ninguém discute.
Mas temos casos de consultas extremamente co mpelxas em que um relatório demorava 8 minutos pra ser executado no hibernate sendo que no SQL demorava 15 segundos, sem falar a diferença de consumo de memória. Outros casos era ainda pior, o relatório simplesmente não conseguia executar.
E aí, vamos usar Hibernate? Fala com seu diretor :lol:
[/quote]
E onde isso tem a ver com a discussão relacionada ao título desse tópico?
"
[quote=marcosalex][quote=Emerson Macedo]
E onde isso tem a ver com a discussão relacionada ao título desse tópico?[/quote]
Tem a ver com a resposta que me deram. O título do tópico eu ja respondi, dá uma olhada na página anterior com atenção e você vai achar.[/quote]
Eu já havia lido todo o tópico não vejo relevância nessa discussão para esse momento já que o tópico não tem relação com isso. Em todo caso já foi esclarecido.
Olá!
Acredito que essa cultura de criar primeiro o modelo da base de dados e depois partir pro domínio é algo que ainda vai perdurar por um bom tempo, não que seja errado, é só uma abordagem diferente. (Algo parecido com falar que programar estruturado é errado e programar OO é certo, o que é uma baita burrice, são apenas abordagens diferentes)
Outra coisa também que acho é que certas coisas deviam ficar na base de dados, como log, arquivo morto e auditoria (por meio de Triggers), relatórios (por meio de Views) e outras coisas que não lembro no momento. Se houver alguma besteira, por favor me corrijam, só não vale dizer que deixar essas coisas no SGBD amarra a aplicação com determinado tipo de banco de dados, até porque qualquer distribuição de SGBD tem essas funcionalidades além de ser bem dificil uma aplicação migrar a “marca” de sua base de dados. (Não aplicações sérias).
Abraços
O ponto que muitos defendem (eu inclusive) é que o Core das aplicações que a maioria aqui desenvolve no dia a dia (i.e. sistemas de informação) deve ser implementado em Objetos e não no banco. Mas é lógico que toda regra tem sua exceção. Como você bem disse, existem algumas coisas que podem fazer mais sentido estar no banco. Isso deve ser analisado caso a caso. O que pra mim não faz sentido é pegar uma aplicação que faz CRUD e criar uma stored procedure para cada ação como alguns defendem e é ensinado em diversas faculdades, inclusive as que frequentei.
Sim, nisso eu assino embaixo (concerteza partir da análise do dominio deixa seu modelo de negócios mais… digamos… natural). E a intensidade dessa defesa varia de acordo com tamanho do ego do professor de banco de dados… :lol: heuheauheauheau
Sim, nisso eu assino embaixo (concerteza partir da análise do dominio deixa seu modelo de negócios mais… digamos… natural). E a intensidade dessa defesa varia de acordo com tamanho do ego do professor de banco de dados… :lol: heuheauheauheau [/quote]
Ai você tocou num ponto sensível, o ego.
Que atire a primeira pedra quem nunca viu um DBA e um administrador de redes megalomaníaco com síndrome de Deus.
Sad, but true.
Gosto muito de criar o modelo OO e deixar que a ferramenta que se vire na criação das tabelas, só uma pena que não se use orientação a objetos no modelo de banco de dados na maioria dos casos.
Tai uma das coisas que me animam a estudar arquitetura e modelagem.
Abraços.
Ola,
Eu nao tenho uma carta magica para reabrir o topico como vi em outro topico outro dia hehehe. Mas reabrindo a discursao, eu sempre achei melhor criar o dominio a partir do banco por questoes de facilidade. Criar o banco numa ferramenta como o Worbench, por exemplo, e depois importar as classes. Mas ultimamente ocorreu uma questao que nao havia precisado ainda. heranca. Quando o modelo da aplicação ira precisar ter herança o Netbeans por exemplo nao importa as classes com ela. Nesse caso sao as questoes manuais que se fala? ou tem ferramentas para importar ja com a heranca? um exemplo simples para essa heranca seria Pessoa, PessoaJuridica, PessoaFisica, Fornecedor e Cliente.
[quote=thimor]Ola,
Eu nao tenho uma carta magica para reabrir o topico como vi em outro topico outro dia hehehe. Mas reabrindo a discursao, eu sempre achei melhor criar o dominio a partir do banco por questoes de facilidade. Criar o banco numa ferramenta como o Worbench, por exemplo, e depois importar as classes. Mas ultimamente ocorreu uma questao que nao havia precisado ainda. heranca. Quando o modelo da aplicação ira precisar ter herança o Netbeans por exemplo nao importa as classes com ela. Nesse caso sao as questoes manuais que se fala? ou tem ferramentas para importar ja com a heranca? um exemplo simples para essa heranca seria Pessoa, PessoaJuridica, PessoaFisica, Fornecedor e Cliente.[/quote]
Eu podia por a carta magina de novo, mas não vo por ahuahuahu.
Usamos muito o netbeans aqui para reimportar as classes direto do banco, e em casos de herança em base o netbeans importa como se fosse tudo uma coisa só.
Pelo que percebi esse esquema de heranca deve ser manual mesmo.
abracos.
DBA se acha Deus porque ele cuida de um dos principais ativos de uma empresa: informação.
Será que o CEO/Diretor e o CIO de uma empresa dormiriam tranquilos sabendo que seus dados estão sob responsabilidade de um Javeiro/Hiberneteiro?
Esse negócio de DBA x Desenvolvedor pra mim é besteira, da mesma foram que a guerra entre qual diagrama. Com as ferramentas que sincronizam códigos e diagramas, cada um parte de onde preferir e as próprias ferramentas geram o resto.
Particularmente acho mais fácil partir de um diagrama de classes, mas não vejo problema nenhum se a pessoa preferir sair pelo DER.
[quote=andre_mbm]DBA se acha Deus porque ele cuida de um dos principais ativos de uma empresa: informação.
Será que o CEO/Diretor e o CIO de uma empresa dormiriam tranquilos sabendo que seus dados estão sob responsabilidade de um Javeiro/Hiberneteiro?[/quote]
Enquanto esse tipo de pensamento durar, os softwares continuarao sendo ruins e as bases de dados, “tunadas”, continuarao cheia de informacoes inconsistentes.
Informacao voce pode guardar em qualquer lugar, até no excel, se elas estao numa SGDB é porque vao ser processadas de alguma forma.
Acreditar que os dados armazenados valem mais que os processos é o que faz com que a grande maioria das empresas de desenvolvimento entreguem softwares ridiculos, produzidos por programadores juniors, mais conhecidos como javeiro e hibernateiros.
como eu aprendi primeiro o modelo relacional, eu prefiro fazer ele primeiro