Wybór strategii zachowania hierarchii

Opis

Każda z powyższych strategii i technik ma swoje zalety i wady. Ogólne zalecenia dotyczące wyboru konkretnej strategii będą wyglądać następująco:

Strategia TABLE_PER_CLASS oparta na UNION

Tę strategię najlepiej wybrać, jeśli nie są wymagane zapytania polimorficzne i asocjacje. Jeśli rzadko to robisz (lub nie robisz wcale) „wybierz użytkownika z użytkownika użytkownika”. Jeśli nie masz żadnych klas Entity, które odnoszą się do użytkownika, jest to najlepsza opcja (ponieważ nadal możesz dodawać zoptymalizowane zapytania polimorficzne i powiązania).

Strategia SINGLE_TABLE

Tę strategię należy zastosować:

a) Tylko do prostych zadań. W sytuacjach, w których normalizacja i ograniczenie NOT NULL są krytyczne, preferowana powinna być strategia nr 3 (JOINED). Warto zastanowić się, czy w takim przypadku nie warto całkowicie zrezygnować z dziedziczenia i zastąpić go delegacją.

b) Jeśli wymagane są zapytania polimorficzne i asocjacje, a także dynamiczna definicja konkretnej klasy w czasie wykonywania. Jednocześnie podklasy deklarują stosunkowo niewiele nowych pól, a główna różnica w stosunku do nadklasy polega na zachowaniu.

A do tego masz poważną rozmowę z DBA.

DOŁĄCZONA strategia

Ta strategia jest najbardziej efektywna pod względem szybkości i OGRANICZEŃ. Jest odpowiedni w przypadkach, gdy wymagane są zapytania polimorficzne i asocjacje, ale podklasy deklarują stosunkowo wiele nowych pól.

Tu uwaga: decyzja między JOINED a TABLE_PER_CLASS wymaga oceny planów wykonania zapytania na rzeczywistych danych, ponieważ szerokość i głębokość hierarchii dziedziczenia może sprawić, że koszt łączenia (a co za tym idzie wydajność) będzie nie do zaakceptowania.

Osobno warto wziąć pod uwagę, że adnotacje dziedziczenia nie mogą być stosowane do interfejsów.

WYRAŹNY

Może również wystąpić sytuacja, w której masz hierarchię klas Entity ze współdzieloną strategią przechowywania w bazie danych. Ale z jakiegoś powodu nie chcesz, aby jakaś klasa hierarchii była zwracana, gdy zapytanie jest kierowane do klasy bazowej.

Jest na to adnotacja:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Jeśli dodamy to do klasy 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;
}

Wtedy zapytania HQL będą ignorować obiekty tej klasy podczas wysyłania zapytań do klasy bazowej:

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

To zapytanie zwróci listę obiektów User i Employee , ale nie Client .