📊 Capítulo 06: Relacionamentos JPA & FetchType

Especialização Backend com Java 21 & Spring Boot 3

🗺️ O Dilema do FetchType: LAZY vs EAGER & Problema N+1

flowchart TD
    QUERY["SELECT p FROM Pedido p (100 pedidos)"]
    --> STRATEGY{"Estratégia de Fetch nos Itens"}
    STRATEGY --> |"FetchType.EAGER / LAZY ingênuo"| N_PLUS_ONE["🚨 O Problema N+1: 1 SELECT principal + 100 SELECTs secundários (101 queries no banco!)"]
    STRATEGY --> |"JOIN FETCH / EntityGraph"| OPTIMIZED["⚡ Otimizado: 1 ÚNICO SELECT com INNER/LEFT JOIN trazendo pedidos e itens juntos!"]

    style QUERY fill:#ede7f6,stroke:#512da8,stroke-width:2px
    style STRATEGY fill:#fff3e0,stroke:#ff9800,stroke-width:1.5px
    style N_PLUS_ONE fill:#ffebee,stroke:#d32f2f,stroke-width:2px
    style OPTIMIZED fill:#e8f5e9,stroke:#4caf50,stroke-width:2px

🎯 Slide 1: Tipos Fundamentais de Associação

• @ManyToOne: Muitos pedidos para um único cliente (Lado proprietário da FK).

• @OneToMany(mappedBy = "cliente"): Um cliente para muitos pedidos (Coleção gerenciada).

• @ManyToMany & @JoinTable: Associação muitos-para-muitos com tabela intermediária.

• orphanRemoval = true: Remove automaticamente do banco filhos removidos da coleção Java.

🎯 Slide 2: Boas Práticas Estritas de FetchType

• Regra de Ouro da Indústria: Configure SEMPRE FetchType.LAZY em todas as relações (@ManyToOne, @OneToMany, @ManyToMany).

• Por Que Evitar EAGER? O FetchType.EAGER padrão de @ManyToOne dispara joins ocultos gigantes mesmo quando você só precisa do ID do pai!

🎯 Slide 3: Resolvendo o Problema N+1 com JOIN FETCH

public interface PedidoRepository extends JpaRepository<Pedido, Long> {

    @Query("SELECT p FROM Pedido p JOIN FETCH p.itens WHERE p.status = :status")
    List<Pedido> buscarComItensPorStatus(@Param("status") StatusPedido status);
}

• O JOIN FETCH força o Hibernate a carregar os filhos em uma única viagem ao banco de dados (Single Round-Trip).