pessoal, tem várias formas de associar duas tabelas, tem a mais recomendada a cada tipo de situação? ou isso é só na documentação? por exemplo:
public class Contato {
private long id;
private String nome;
private String segundoNome;
private String sobreNome;
private Telefone telefone;
//gets e sets
}
[code]
public class Telefone {
private long id;
private String telefoneFixo;
private String telefoneCelular;
private Contato contato;
//gets e sets
}[/code]
no banco só vão referencias a chaves primárias se tornando na outra taqbela chaves estrangeiras, ok!!(simplificando)
mas,
na UML criei uma associação de composição(sem contato não existe telefone) e seja qual for a configuração no Jude, ele sempre cria em “Contato” a propriedade “Telefone telefone”, tá certo isso ou seria melhor substituir por “telefone long; // chave estrangeira referenciando PK de Telefone.id” ?
no banco não enchergo outra forma de fazer se não a troca de chaves, mas no código da aplicação? existe melhor opção para cada caso? sempre uso o tipo da outra classe? sempre uso as respectivas chaves?
nesse código acima, houve uma troca entre as duas classes de suas chaves, eu estava imaginando só precisar fazer referência na classe “Contato”, estou certo ou assim tb serve?
cara… com um relacionamento assim, porque não colocas um campo simples de telefone em contato ??? Só vejo vantagem em modelar uma entidade telefone se o mesmo for usado pra mais de 1 contato…
Me ignora… hueheueheueheue agora que vi que em tua entidade telefone, podes ter Ns tipos de telefones…
Apesar de ainda ver um modelo confuso…
Ainda acho que devias ter um relacionamento N - N e uma nova entidade TelefonesContato.
Não sei qual a tua necessidade, mas por exemplo, nos sistemas em que precisava de um contato de telefone, podia ter um irmão ou o cadastro de uma família inteira em um mesmo telefone, aí aproveitávamos a entidade…
claro que esse modelo é extremamente simplificado, ele serve apenas para o enfoque nas associações.
eu deveria ter associações muitos para muitos? acha memso necessário?
só quero saber como deve ficar a troca de código entre as classes, se apenas uma recebe código da outra ou se as duas recebem e quando receber, se vai receber uma cópia de um valor “long” da chave primária da outra classe ou o tipo da classe.
a classe Contato está com uma propriedade do tipo Telefone, isso serve para o que descrevo? ou seria melhor apenas receber o valor da chave primária de Telefone? ou tato faz?
a classe Telefone também está com um campo de tipo Contato, está certo ou não precisa?
public class Contato {
private long id;
private String nome;
private String segundoNome;
private String sobreNome;
private Telefone telefone;
//gets e sets
}
[code]
public class Telefone {
private long id;
private String telefoneFixo;
private String telefoneCelular;
private Contato contato; <------- pq isso?
//gets e sets
}[/code]
Eu nao entendi o pq do contato na classe telefone:
.....
private Contato contato;
.....
Eu faria assim:
public class Contato {
private long id;
private String nome;
private String segundoNome;
private String sobreNome;
private ArrayList<Telefone> telefone;
//gets e sets
}
[code]
public class Telefone {
private long id;
private String telefone;
private String tipoTelefone;
//gets e sets
uma lista? hummmm
será que de alguma forma, não daria mais trabalho na hora de percorrer os números na hora de uma busca??? mas é interessante pq retira a limitação de números apra cadastrar. No banco essa lista iria virar 1 para Muitos, certo?
uma lista? hummmm
nessa tabela ficaria todas as opções de números e mais, assim acredito não precisar dessa lista, sacou? o que acha?
acho que aki não seria necessário uma coleção do tipo Telefone, a não ser que fosse uma lista de números.
fui editar deu errado…
sim, mas criando uma tabela telefone com campos distintos para cada tipo de número telefônico, vou precisar criar uma lista com o tipo da classe? entenderia o que vc quer se vc tivesse criado uma lista de números(os números de telefones).
eu já tinha dito que entendi o que vc sugeriu.
desmembrar dá trabalho inicial mas dá posteriormente mais flxibilidade, mas deixar descrição em uma tabela diferente, acho de mais.
no meu caso acredito não ser necessário a classe associativa, terá apenas uma instância de Telefone para Contato, já que não é necessário a possibilidade de uma lista gigante de opções telefonicas.
de novo…
em Contato deve ficar:
Telefone telefone;
ou
long id_telefone;
[quote=daquinho]eu já tinha dito que entendi o que vc sugeriu.
desmembrar dá trabalho inicial mas dá posteriormente mais flxibilidade, mas deixar descrição em uma tabela diferente, acho de mais.
no meu caso acredito não ser necessário a classe associativa, terá apenas uma instância de Telefone para Contato, já que não é necessário a possibilidade de uma lista gigante de opções telefonicas.
de novo…
em Contato deve ficar:
Telefone telefone;
ou
long id_telefone;[/quote]
usar na propriedade um tipo de outra classe, facilita na hora de acessar os dados dessa classe, mas isso está aumentando a acoplação entre as classes né?
acho que vou apenas trocar as chaves…
outra coisa, no meu diagrama, enchergo apossiblidade de agregação ou composição,entre algumas classes, se existir a possiblidade tenho que fazer?quando que eu vou optar por apenas associação simples?
estou viajando na batatinha? composiçaõ ,agregação e associação simples são apenas uma questão de visão na documentação? como vai amarrar seu código?
estou num impasse se encho os diagramas de agregações e composições.
classes Contato, Telefone, Empresa e Endereço. Contato e Empresa tem associação com Telefone, Telefone sozinho não existe, mas um contato e uma empresa não são obrigados a ter Telefone, assim como um Endereço cadastrado. Agregação ou associação simples?
