hibernate
Prestatie afstemmen

Gebruik geen EAGER-ophaaltype

Slaapstand kan twee soorten ophalen gebruiken wanneer u de relatie tussen twee entiteiten in kaart brengt: EAGER en LAZY .

Over het algemeen is het EAGER geen goed idee, omdat het JPA vertelt om de gegevens altijd op te halen, zelfs wanneer deze gegevens niet nodig zijn.

Als u bijvoorbeeld een entiteit Person en de relatie met Address als volgt:

@Entity
public class Person {

  @OneToMany(mappedBy="address", fetch=FetchType.EAGER)
  private List<Address> addresses;

}

Elke keer dat u te vragen een Person , de lijst van Address van deze Person zal ook worden geretourneerd.

Dus in plaats van uw entiteit in kaart te brengen met:

@ManyToMany(mappedBy="address", fetch=FetchType.EAGER)

Gebruik:

@ManyToMany(mappedBy="address", fetch=FetchType.LAZY)

Een ander ding om op te letten zijn de relaties @OneToOne en @ManyToOne . Beide zijn standaard EAGER. Dus als u zich zorgen maakt over de prestaties van uw toepassing, moet u de ophaalactie instellen voor dit type relatie:

@ManyToOne(fetch=FetchType.LAZY)

En:

@OneToOne(fetch=FetchType.LAZY)

Gebruik compositie in plaats van overerving

Slaapstand heeft een aantal overervingsstrategieën. Het JOINED overervingstype doet een JOIN tussen de onderliggende entiteit en de bovenliggende entiteit.

Het probleem met deze aanpak is dat Hibernate altijd de gegevens van alle betrokken tabellen in de overerving brengt.

Als u bijvoorbeeld de entiteiten Bicycle en MountainBike gebruikt met het type JOINED inheritance:

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class Bicycle {

}

En:

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public class MountainBike extends Bicycle {

}

Elke JPQL-zoekopdracht die MountainBike treft, levert de gegevens van de Bicycle op en creëert een SQL-zoekopdracht zoals:

select mb.*, b.* from MountainBike mb JOIN Bicycle b ON b.id = mb.id WHERE ...

Als u een andere ouder voor Bicycle (zoals Transport , bijvoorbeeld), brengt deze bovenstaande zoekopdracht de gegevens van deze ouder ook, en doet een extra JOIN.

Zoals u kunt zien, is dit ook een soort EAGER toewijzing. U hebt niet de keuze om alleen de gegevens van de MountainBike tabel mee te nemen met behulp van deze overervingsstrategie.

De beste prestatie is gebruikssamenstelling in plaats van overerving.

Om dit te bereiken, kunt u de entiteit MountainBike toewijzen aan een bicycle :

@Entity
public class MountainBike {

    @OneToOne(fetchType = FetchType.LAZY)
    private Bicycle bicycle;

}

En Bicycle :

@Entity
public class Bicycle {

}

Elke zoekopdracht levert nu standaard alleen de MountainBike gegevens op.