Por que não incluir uma Foreign Key "id_emprestimo" em "TabelaPagamentos", se é necessário que um pagamento esteja atrelado a um empréstimo?
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
Solucionado
Por que não incluir uma Foreign Key "id_emprestimo" em "TabelaPagamentos", se é necessário que um pagamento esteja atrelado a um empréstimo?
Ótima pergunta — e, na verdade, a resposta está justamente na garantia de integridade referencial do seu banco de dados.
Se cada pagamento está relacionado a um único empréstimo, **incluir uma Foreign Key (id_emprestimo) na TabelaPagamentos é altamente recomendado e, em muitos casos, necessário.
Por que incluir a Foreign Key? Integridade referencial:
A Foreign Key garante que nenhum pagamento será associado a um empréstimo inexistente.
Exemplo: impede que você cadastre um pagamento com id_emprestimo = 99 se esse empréstimo não existir na tabela de empréstimos.
Relações claras no modelo de dados:
Facilita entender que existe uma relação de 1:N (um para muitos) entre empréstimos e pagamentos.
Um empréstimo pode ter muitos pagamentos, mas um pagamento pertence a um único empréstimo.
Consultas mais seguras e eficientes:
Ajuda a realizar joins entre tabelas com mais segurança e desempenho.
Facilita a criação de índices otimizados.
Evita dados órfãos:
Se um empréstimo for excluído, você pode definir regras para o que fazer com os pagamentos associados (ON DELETE CASCADE, por exemplo).
Quando não incluir uma Foreign Key? Raramente faz sentido não incluir, mas há casos muito específicos:
Quando se trabalha com bancos NoSQL, que não utilizam Foreign Keys.
Quando você está deliberadamente evitando restrições por conta de performance extrema (mesmo assim, ainda é importante garantir isso via aplicação).
Quando a aplicação precisa de flexibilidade acima da integridade (por exemplo, em dados temporários, logs, ou importações parciais).