OO ou SQL

Não entendi sua dúvida…

Você está perguntando se é melhor criar primeiro as classes Java, pra depois criar as tabelas do banco de dados, ou vice-versa?

Sim, justamente isso…

Tou perguntando qual o beneficio de primeiro criar as Strucks ( Classes em Java ) ou já ir direto ao SQL ( Ja persistir os dados no banco de dados ).

DouglasBaltazar:

Sim, justamente isso...

Tou perguntando qual o beneficio de primeiro criar as Strucks ( Classes em Java ) ou já ir direto ao SQL ( Ja persistir os dados no banco de dados ).

Já digitou isso no google?
gerar tabelas automaticamente hibernete?

http://www.guj.com.br/java/213441-criar-tabelas-com-hibernate-a-partir-do-mapeamento-resolvido

Tópico mais sem sentido.

Como alguém pode saber a melhor situação se você nem ao menos descreveu qual o seu caso?

Ao criar primeiro o SQL e depois as classes você pode acabar orientando seu projeto iguais as tabelas, e se houver algum erro de design lá, você levará esse erro para sua classe.

Sempre primeiro em OO. Sempre.

Se eu fizer só o SQL?

Tipo faço a classe Cliente, e não orientar ao objeto, e sim orientar ao SQL, não é melhor q fazer as 2 orientações?

Cara se você fizer somente baseado somente na ER e largar de mão a OO você perderá o que ela tem de melhor. Boa sorte!!!

Nem sempre, tem casos de empresas, geralmente nas grandes, em que existem N sistemas em diversas tecnologias orientadas a objetos ou não mas que podem compartilhar o mesmo banco de dados. Não é o cenário academicamente perfeito, mas é uma realidade. Então tem situações que o banco é quem “manda”. Você define junto com o AD a modelagem, onde ele vai se preocupar com o todo (não só o seu sistema). Você até cria seu modelo de classes do jeito que quiser, mas a tabela tem que ser de acordo com a administração de dados. Então tem casos que a tabela vem primeiro para não ter retrabalho de modelagem.

Depende do caso, usar OO ou não, ou até mesmo ER ou não.

Alguns links interessantes:

Na minha opinião, no meu sistema, acho perca de tempo, em passar para a OO para depois passar novamente para o SQL…

Pois, eu poderia usar as classes de usar o OO já fazer o get pegando dentro do SQL e o set Setando dentro do SQL…

Na minha opinião, seria melhor que ficar passando para a classe e depois passar novamente para o SQL

DouglasBaltazar:

Na minha opinião, no meu sistema, acho perca de tempo, em passar para a OO para depois passar novamente para o SQL…

Pois, eu poderia usar as classes de usar o OO já fazer o get pegando dentro do SQL e o set Setando dentro do SQL…

Na minha opinião, seria melhor que ficar passando para a classe e depois passar novamente para o SQL

Pessoal, acho que vocês entenderam errado, ele não está perguntando se é melhor construir o sistema pensando no sql ou em oo.

Pelo que entendi tu quer sempre acessar o banco a partir do teu objeto, ao invés de definir atributos e usar uma classe controller pra acessar o banco.

Isso é ruim por uma série de motivos, mas os mais visíveis agora é que se tu fizer isso vai gerar muitas requisições no banco(agora imagina N usuários fazendo isso), assim tu nunca vai conseguir garantir a integridade dos teus dados. Imagina pra cada alteração em teu objeto tu fazer um update ou algo do tipo. Tu vai gerar um stress no banco desnecessário.

Desculpa se entendi a tua pergunta errado hehehe.

DouglasBaltazar:

Na minha opinião, no meu sistema, acho perca de tempo, em passar para a OO para depois passar novamente para o SQL…
Pois, eu poderia usar as classes de usar o OO já fazer o get pegando dentro do SQL e o set Setando dentro do SQL…
Na minha opinião, seria melhor que ficar passando para a classe e depois passar novamente para o SQL

Como já foi dito, em termos de desempenho não é nada bom fazer um Select para cada getAtributo ou Insert/Update para cada setAtributo.
Com apenas 1 select pega todos os dados do registro e seta todos atributos do objeto, depois só quando alterar executa Update.

Está usando JDBC puro? O Projeto é para fins de estudo ou uso mesmo?

Como já foi dito, em termos de desempenho não é nada bom fazer um Select para cada getAtributo ou Insert/Update para cada setAtributo.
Com apenas 1 select pega todos os dados do registro e seta todos atributos do objeto, depois só quando alterar executa Update.

Está usando JDBC puro? O Projeto é para fins de estudo ou uso mesmo?

Justamente, o que estou fazendo ta em CRUD puro, nada de objetos, tou fazendo com um get e um set para cada atributo a ser pego…

Então você recomenda que eu dê um get, e jogue tudo para um Objeto, e quando deixar de usar esse objeto, dar um Update no Cliente ( O que quero pegar )todo?

DouglasBaltazar:

Justamente, o que estou fazendo ta em CRUD puro, nada de objetos, tou fazendo com um get e um set para cada atributo a ser pego…
Então você recomenda que eu dê um get, e jogue tudo para um Objeto, e quando deixar de usar esse objeto, dar um Update no Cliente ( O que quero pegar )todo?

é para web ou desktop?

Não acho que existe um jeito melhor. vc quem acaba escolhendo a forma.
isso pode depender de quanto em quanto tempo e da forma como dará manutenção, de como quer apresentar os dados…
Se vc tiver se preocupando com dados que podem ou não ser visualizados pelo usuário, eu também consideraria a forma como está fazendo boa (do SQL para o Java).

além de gerar as tabelas pelo mapeamento de suas classes, vc pode fazer o inverso também. Olha esse exemplo:

outra sugestão… existem formas de vc gerar o codigo apartir das tabelas do seu banco.

Sim, acho realmente melhor q eu faça direto do SQL, já que não se vai usar UPDATEs toda hora, já que nao vai estar em constante mudança…

Estou fazendo com o plugin de jdbc para o uso de postgre…

e estou usando para desktop…