Estou fazendo um Sistema em Java + PostgreSQL.
Qual a melhor situação?
Fazer um Orientado ao Objeto e depois passar ao SQL, ou ja passar direto ao SQL?
E quais os beneficios de usar OO e dps 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 ).
[quote=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 ).
[/quote]
Já digitou isso no google?
gerar tabelas automaticamente hibernete?
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
[quote=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[/quote]
Voce não especificou seu caso e cenário, então fica difícil dizer o que pode ser melhor. Mas supondo que fosse melhor OO, mais tarde seu projeto pode ficar difícil de evoluir, ninguem além de voce vai querer dar manutenção e a empresa cliente pode ficar na mão. Para facilitar isso que voce falou tem o Hibernate por exemplo, se estiverbusando Java ou .NET.
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.
[quote=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[/quote]
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?
[quote]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?[/quote]
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?
[quote=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? [/quote]
é 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…