Att välja en hierarkibevarandestrategi

Beskrivning

Var och en av ovanstående strategier och tekniker har sina egna fördelar och nackdelar. Allmänna rekommendationer för att välja en specifik strategi kommer att se ut så här:

TABLE_PER_CLASS-strategi baserad på UNION

Denna strategi är bäst att välja om polymorfa frågor och associationer inte krävs. Om du sällan gör (eller inte gör det alls) "välj användare från Användaranvändare". Om du inte har entitetsklasser som hänvisar till Användare är detta det bästa alternativet (eftersom du fortfarande kan lägga till optimerade polymorfa frågor och associationer).

SINGLE_TABLE-strategi

Denna strategi bör användas:

a) Endast för enkla uppgifter. I situationer där normalisering och NOT NULL-begränsningen är kritiska bör strategi #3 (JOINED) föredras. Det är vettigt att fundera på om det i det här fallet inte är värt att helt överge arvet och ersätta det med delegering.

b) Om polymorfa frågor och associationer krävs, samt dynamisk definition av en konkret klass vid körning. Samtidigt deklarerar underklasser relativt få nya fält, och den största skillnaden med en superklass är beteendet.

Och utöver det har du ett seriöst samtal med DBA.

ANSLUTADE strategi

Denna strategi är den mest effektiva när det gäller hastighet och BEGRÄNSNINGAR. Det är lämpligt i fall där polymorfa frågor och associationer krävs, men underklasser deklarerar relativt många nya fält.

Ett varningens ord här: beslutet mellan JOINED och TABLE_PER_CLASS kräver utvärdering av frågeexekveringsplaner på verkliga data, eftersom bredden och djupet på arvshierarkin kan göra kostnaden för sammanfogningar (och, som ett resultat, prestanda) oacceptabla.

Separat är det värt att ta hänsyn till att arvsanteckningar inte kan tillämpas på gränssnitt.

EXPLICIT

Det kan också finnas en situation där du har en hierarki av Entity-klasser med en delad lagringsstrategi i databasen. Men oavsett anledning vill du inte att någon hierarkiklass ska returneras när en fråga görs på basklassen.

Det finns en anteckning för detta:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Om vi ​​lägger till det i klientklassen :

@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;
}

Då kommer HQL-frågor att ignorera objekt av denna klass när de frågar basklassen:

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

Denna fråga returnerar en lista med användar- och anställdsobjekt , men inte klient .