Beschrijving

Elk van de bovenstaande strategieën en technieken heeft zijn eigen voor- en nadelen. Algemene aanbevelingen voor het kiezen van een specifieke strategie zien er als volgt uit:

TABLE_PER_CLASS strategie gebaseerd op UNION

Deze strategie kan het beste worden gekozen als polymorfe query's en associaties niet vereist zijn. Als u zelden (of helemaal niet doet) "select user from User user" doet. Als u geen Entity-klassen hebt die naar User verwijzen, is dit de beste optie (omdat u nog steeds geoptimaliseerde polymorfe query's en associaties kunt toevoegen).

SINGLE_TABLE-strategie

Deze strategie moet worden gebruikt:

a) Alleen voor eenvoudige taken. In situaties waarin normalisatie en de NOT NULL-beperking van cruciaal belang zijn, verdient strategie #3 (JOINED) de voorkeur. Het is logisch om na te denken of het in dit geval niet de moeite waard is om de erfenis volledig op te geven en te vervangen door delegatie.

b) Als polymorfe vragen en associaties vereist zijn, evenals dynamische definitie van een concrete klasse tijdens runtime. Tegelijkertijd declareren subklassen relatief weinig nieuwe velden, en het belangrijkste verschil met een superklasse zit hem in het gedrag.

En bovendien heb je een serieus gesprek met de DBA.

GEZAMENLIJKE strategie

Deze strategie is het meest efficiënt in termen van snelheid en BEPERKINGEN. Het is geschikt in gevallen waarin polymorfe query's en associaties vereist zijn, maar subklassen declareren relatief veel nieuwe velden.

Een waarschuwing hier: de beslissing tussen JOINED en TABLE_PER_CLASS vereist evaluatie van query-uitvoeringsplannen op echte gegevens, aangezien de breedte en diepte van de overervingshiërarchie de kosten van joins (en als gevolg daarvan de prestaties) onaanvaardbaar kunnen maken.

Afzonderlijk is het de moeite waard om er rekening mee te houden dat overervingsannotaties niet kunnen worden toegepast op interfaces.

EXPLICIET

Er kan ook een situatie zijn waarin u een hiërarchie van Entiteitsklassen hebt met een gedeelde opslagstrategie in de database. Maar om welke reden dan ook, u wilt niet dat een bepaalde hiërarchieklasse wordt geretourneerd wanneer een query wordt gemaakt op de basisklasse.

Hiervoor is een annotatie:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Als we het toevoegen aan de klasse Client :

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Entity
class User {
  int id;
  String name;
  LocalDate birthday;
}
@Entity
class Employee extends User {
 	String occupation;
 	int salary;
 	LocalDate join;
}
@Entity
@Polymorphism(type = PolymorphismType.EXPLICIT)
class Client extends User {
   String address;
}

Dan negeren HQL-query's objecten van deze klasse bij het opvragen van de basisklasse:

List<User> accounts = session.createQuery("from User").getResultList();

Deze query retourneert een lijst met gebruikers- en werknemersobjecten , maar niet Client .

Java university