O que você faz: Cria o modelo E/R no banco, ou gera ele a partir do modelo de classes?

Prefiro mil vezes criar o modelo de classes e deixar o framework cuidar do banco de dados pra mim. Mas só tenho feito isso com meus projetos pessoais, porque no local onde trabalho atualmente precisamos iniciar a modelagem do sistema pelo modelo E/R e depois gerar as classes.

Olá, tbm prefiro a abordagem de criar as classes e deixar o framework de persistencia cuidar do banco. Na verdade quando estou modelando as classes esqueço que tenha um banco de dados;

Como você está (teoricamente) desenvolvendo um sistema orientado a objetos, nada mais natural do que você pensar em objetos quando estar desenvolvendo, e não em tabelas. Creio que é a maneira mais fácil.

Mas como disse o tnaires, muitas empresas ‘exigem’ (até mesmo os clientes) que se faça primeiro a modelagem do banco.

[]´s

Sempre que possivel comece pelos objetos, eles eh que vao determinar o comportamento do sistema. Depois crie um lugar para armazena-los. Eu faço o modelo do banco incrementalmente, depois dos objetos implementados e testados.

Bom isso varia em função da metodologia que se estiver utilizando, por exemplo,no OPENUP o diagrama de classes vem antes de qualquer coisa na fase de elaboração, sendo que o MER vem somente depois de modelada as funcionalidades da iteração, dessa forma tanto o diagrama de classe como o MER vão evoluindo incrementalmente. Mas por outro lado se você estiver usando JDBC você não tem framework o que teoricamente não faria diferença entre um e outro sendo que no final das contas você vai mapear a classe para a tabela mesmo. Mas ainda sim prefiro primeiro pensar em classes e objetos, para só depois pensar em tabelas.

É, nesse caso não há como escapar, tem que criar o modelo físico na mão - preferencialmente após a criação do modelo de classes. Mas tendo uma ferramenta como o Hibernate, que pode criar o modelo de dados incrementalmente, podemos esquecer (quase) completamente que há um banco por trás de tudo.

Nossa, se na realidade do mundo corporativo viesse a UML antes, meu Deus, eu estaria nas nuvens!

Amigo, aonde você leu isso no OpenUP?

Já leram o beabá?

http://www.agiledata.org/essays/culturalImpedanceMismatch.html

Esse aqui é o mais importante:

http://www.agiledata.org/essays/drivingForces.html

Resumo: Projetos OO são os objetos que dirigem a construção do seu modelo de banco. Cuidado com o DBAzinhos que querem manter seus empregos. Eles ficam com aquelas masturbações mentais do tipo “ah… esse indice tá errado… ah… esse relacionamento deve ser trocado… ah… isso não tá normalizado…”… Nesses dias com Hibernate, CouchDB, Caching de Objetos e outras coisitas mais os DBAs perderam bastante “poder”. Já faz uns bons 5 anos que não sinto falta deles nos meus projetos. Melhorar a performance do banco é algo que qualquer programador deve saber…

Amigo, aonde você leu isso no OpenUP?

Se tu achar um diagrama MER na fase de elaboração te dou um prêmio…
http://epf.eclipse.org/wikis/openuppt/

E mais outra não quer dizer que não pode, mas a metodologia não diz.

laudenpower:

Se tu achar um diagrama MER na fase de elaboração te dou um prêmio…
http://epf.eclipse.org/wikis/openuppt/

Se você achar um MER em todo o OpenUp EU TE DOU UM PRÊMIO.

Pensando no Uncle Bob “Aquilo que matou o RUP vai matar o Agile também”, vou blogar sobre isso também…

"

marcosalex:

O maior problema que vejo é que o Hibernate nem sempre consegue gerar as querys mais otimizadas e ainda dá muito perda de performance se comparado ao SQL “puro”. Relatórios complexos, por exemplo, ainda sou obrigado a criar uma query SQL otimizada.

Eu nunca tive problemas de performance com o Hibernate, a perda em relacao ao JDBC puro nao eh tao grande. Agora em relatorios mais complexos eu concordo com vc, eu uso bastante sql direto, mais pela simplicidade do sql do que pela performance, mas uso.

Essa eh uma coisa que me irrita profundamente, eu trabalho atualmente numa empresa que nao utiliza o processo agil, mas pensa que utiliza. Os gerentes leem meia duzia de artigos, fazem uma reuniao por dia pra controlar o trabalho dos desenvolvedores e dizem que isso é scrum. Pra se ter uma ideia, testes unitarios nao sao obrigatorios, o progrmador que quiser faz. Seria hilario se eu nao estivesse bem no meio disso tudo.

Nao preciso nem dizer que muitos dos conceitos pregados pelas metodologias ageis fazem a empresa inteira arregalar os olhos de espanto, como se o que eu estivesse dizendo fosse algo absurdo, de outro mundo. Teste primeiro? pra que se tem equipe de teste? Modelar no código? Isso faz eles cairem da cadeira, tamanho o espanto. E nao adianta mostrar que escrever uma classe no eclipse e fazer a reversa, por numa moldura banhada a ouro e pendurar na sala deles é mais rapido que diagramar com qualquer ferramenta.

E quando falha o projeto de quem é a culpa? Esse tal de scrum ai que nao presta.

"

Eu não tenho o habito de usar uma ferramenta pra gerar o modelo relacional, mas tenho o hábito de desenhar o modelo relacional a partir da modelagem OO. Tem mesmo muitas empresas que exigem o modelo do banco antes, o que é péssimo e como já disseram aí parece ser mais uma artimanha pra segurar empregos de DBAs.

"

Nao creio que seja artimanha, é só a forma de trabalhar que é diferente, dando mais importancia aos dados do que a regra. Mas é uma forma que tem dado certo, nao pra condenar totalmente. E enquanto as metodologias ageis nao provarem em larga escala que sao mais rentaveis isso nao vai mudar.

O que eu nao suporto é quando se assume o caos como metodologia e pensa que esta sendo agil.

Quanto aos dbas, um bom dba é importante em aplicacoes grandes, mas ele deve trabalhar em conjunto com os desenvolvedores e se adequar a agilidade da equipe, nao se comportar como a estrela da companhia, como acontece frequentemente.

"

Chegando bem atrasado, me espanta ver gente reclamando que não usa Hibernate porque é mais lento que o JDBC puro, sendo que a maioria parar 95% do que se desenvolve hoje em dia isso não faz a menor diferença.

Em boa parte dos casos o hibernate é até mais rapido que consultas feitas diretamente em sql.

"

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:

"

marcosalex:

Emerson Macedo:

E onde isso tem a ver com a discussão relacionada ao título desse tópico?

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.

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
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.

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.

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.

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?

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