12.2. Foreign Key Mapping
Referência entre objetos vira chave estrangeira entre tabelas.
Resumo
- Associação entre objetos vira chave estrangeira entre tabelas.
- Referência simples (muitos → um): a FK fica na tabela do objeto que referencia.
- Coleção (um → muitos): a FK fica na tabela do lado muitos, apontando para o dono.
- Atualizar coleção: apagar e reinserir, adicionar back pointer, ou comparar com o estado original.
- Não serve para muitos-para-muitos: aí use Association Table Mapping. Cuidado com ciclos ao carregar.
Perguntas-chave
responda de cabeça, depois abraEm uma coleção um-para-muitos, onde fica a FK?
Na tabela do lado muitos (ex.: faixa.album_id).
Por que Foreign Key Mapping não resolve muitos-para-muitos?
Uma única coluna não guarda vários valores; é preciso uma tabela de ligação.
Como evitar laços infinitos ao carregar referências cíclicas?
Usar Identity Map e/ou Lazy Load para não recarregar objetos já carregados.
Exercícios de fixação
0/5 respondidas1.
Album tem uma lista de Faixa. Como fica no banco com Foreign Key Mapping?2.
Um
Funcionario tem várias Habilidade e cada Habilidade pertence a vários funcionários. Foreign Key Mapping resolve?3.
Ao salvar um álbum cuja lista de faixas mudou, qual estratégia simples Fowler cita para atualizar a coleção?
4.
Ao carregar objetos que se referenciam em ciclo, qual padrão evita laço infinito?
5.
Em uma referência simples
Pedido → Cliente, onde fica a chave estrangeira?