Solucionado
Srs, boa tarde!
Eu estou com uma dúvida relacionada á O.O e banco de dados. Eu estou montando um cadastro de empresa com informações básicas: razão social, cnpj etc... Sabemos que toda empresa tem um endereço sendo assim eu devo criar duas classes uma com dados da empresa e outra com dados do endereço, e usar o conceito de composição, correto?
Com relação ao banco de dados, eu devo criar uma unica tabela que contenha os dados das classes empresa e endereço juntos?
Obrigado.
Leandro,
não, o ideal seriam duas tabelas mesmo, uma de endereço e a outra de empresa. Entre elas haveria um relacionamento, uma empresa tem um endereço (um para um ou One to many). Recomendo que faça o curso de SQL antes de iniciar no de JPA.
João,
entendo. Obrigado pelo retorno.
Leandro, discordo com João nesse ponto. Veja: não existem tantas informações assim em um endereço que justifique o uso de duas tabelas. Lembre-se que quando for carregar os dados serão necessárias buscas em duas tabelas para retornar os dados, mesmo que usando uma única instrução SQL (o JPA apenas simplifica o trabalho para nós programadores, o gerenciador de dados que se dane para fazer o trabalho dele, rsrsrs...). Em um programa simples, isso não terá qualquer impacto, mas imagine um sistema complexo, com muitas requisições simultâneas. Isso poderá consumir tempo de processamento nas consultas tempo de conexão com a base de dados. Dividir as classe é uma boa ideia sim, mas dividir as tabelas só se justificaria realmente se você tiver uma condição do tipo um cliente ter vários endereços, por exemplo vários endereços de entrega, faturamento, cobrança, e eventualmente endereços administrativos e residencial. Aí sim, valeria a pena ter duas tabelas, uma com os dados principais do cliente e dos seus endereços, usando um campo diferenciador do tipo. Eu faço isso em meus sistemas; quando há a necessidade de múltiplos endereços, uso duas tabelas, quando preciso apenas de um endereço, coloco seus dados na tabela principal. Ao que parece o seu programa não será muito complexo, e como eu disse a abordagem sugerida pelo João não teria qualquer impacto perceptível na performance, mas minha sugestão é que você trate esse programa como se fosse mais complexo, de forma a praticar os conceitos. Desta forma, imagine que o programa terá vários acessos simultâneos e um volume alto de transações. Isso dará a você uma ideia melhor de como estrutura o programa. Minha experiência me mostra que programas simples se tornam base para sistemas complexos, até por que ao precisar desenvolver algum cadastro de empresa para um sistema maior, você não querer reinventar a pólvora, e irá reaproveitar o código que já criou em um programa mais simples, esse é justamente uma das metas da orientação à objetos: a reutilização de soluções, por mais simples que sejam. O que vocês acham?
Sandro, bom dia!
Eu achei que seu ponto de vista foi excelente. Meus parabéns e muito obrigado pela dica. Vou procurar seguir, sua sugestão.