Auswahl einer Strategie zur Hierarchieerhaltung

Beschreibung

Jede der oben genannten Strategien und Techniken hat ihre eigenen Vor- und Nachteile. Allgemeine Empfehlungen zur Auswahl einer bestimmten Strategie sehen folgendermaßen aus:

TABLE_PER_CLASS-Strategie basierend auf UNION

Diese Strategie eignet sich am besten, wenn keine polymorphen Abfragen und Zuordnungen erforderlich sind. Wenn Sie dies selten (oder überhaupt nicht) tun, wählen Sie „Benutzer aus Benutzerbenutzer“ aus. Wenn Sie keine Entitätsklassen haben, die auf „Benutzer“ verweisen, ist dies die beste Option (da Sie dennoch optimierte polymorphe Abfragen und Zuordnungen hinzufügen können).

SINGLE_TABLE-Strategie

Diese Strategie sollte verwendet werden:

a) Nur für einfache Aufgaben. In Situationen, in denen Normalisierung und die NOT NULL-Einschränkung von entscheidender Bedeutung sind, sollte Strategie Nr. 3 (JOINED) bevorzugt werden. Es ist sinnvoll, darüber nachzudenken, ob es sich in diesem Fall nicht lohnt, ganz auf die Vererbung zu verzichten und sie durch eine Delegation zu ersetzen.

b) Wenn polymorphe Abfragen und Assoziationen erforderlich sind, sowie dynamische Definition einer konkreten Klasse zur Laufzeit. Gleichzeitig deklarieren Unterklassen relativ wenige neue Felder und der Hauptunterschied zu einer Oberklasse liegt im Verhalten.

Und darüber hinaus führen Sie ein ernstes Gespräch mit dem DBA.

JOINED-Strategie

Diese Strategie ist hinsichtlich Geschwindigkeit und EINSCHRÄNKUNGEN am effizientesten. Es eignet sich für Fälle, in denen polymorphe Abfragen und Assoziationen erforderlich sind, Unterklassen jedoch relativ viele neue Felder deklarieren.

Hier ist Vorsicht geboten: Die Entscheidung zwischen JOINED und TABLE_PER_CLASS erfordert die Bewertung von Abfrageausführungsplänen für reale Daten, da die Breite und Tiefe der Vererbungshierarchie die Kosten für Verknüpfungen (und damit die Leistung) inakzeptabel machen kann.

Unabhängig davon ist zu berücksichtigen, dass Vererbungsanmerkungen nicht auf Schnittstellen angewendet werden können.

EXPLIZIT

Es kann auch eine Situation geben, in der Sie über eine Hierarchie von Entitätsklassen mit einer gemeinsamen Speicherstrategie in der Datenbank verfügen. Aus irgendeinem Grund möchten Sie jedoch nicht, dass eine Hierarchieklasse zurückgegeben wird, wenn eine Abfrage für die Basisklasse durchgeführt wird.

Hierzu gibt es eine Anmerkung:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Wenn wir es zur Client- Klasse hinzufügen :

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

Dann ignorieren HQL-Abfragen Objekte dieser Klasse, wenn sie die Basisklasse abfragen:

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

Diese Abfrage gibt eine Liste von User- und Employee -Objekten zurück , jedoch nicht von Client .