Alegerea unei strategii de conservare a ierarhiei

Descriere

Fiecare dintre strategiile și tehnicile de mai sus are propriile sale avantaje și dezavantaje. Recomandările generale pentru alegerea unei strategii specifice vor arăta astfel:

Strategia TABLE_PER_CLASS bazată pe UNION

Această strategie este cel mai bine aleasă dacă nu sunt necesare interogări și asocieri polimorfe. Dacă faceți rar (sau nu faceți deloc) „selectați utilizatorul din utilizatorul utilizatorului”. Dacă nu aveți clase de Entitate care se referă la Utilizator, aceasta este cea mai bună opțiune (pentru că puteți adăuga în continuare interogări și asocieri polimorfe optimizate).

Strategia SINGLE_TABLE

Această strategie ar trebui utilizată:

a) Numai pentru sarcini simple. În situațiile în care normalizarea și constrângerea NOT NULL sunt critice, strategia #3 (JOINED) ar trebui să fie preferată. Este logic să ne gândim dacă în acest caz nu merită abandonarea completă a moștenirii și înlocuirea acesteia cu delegarea.

b) Dacă sunt necesare interogări și asocieri polimorfe, precum și definirea dinamică a unei clase concrete în timpul rulării. În același timp, subclasele declară relativ puține câmpuri noi, iar principala diferență cu o superclasă este în comportament.

Și pe deasupra, aveți o conversație serioasă cu DBA.

strategie JOINED

Aceasta strategie este cea mai eficienta din punct de vedere al vitezei si CONSTRINGRILOR. Este potrivit în cazurile în care sunt necesare interogări și asocieri polimorfe, dar subclasele declară relativ multe câmpuri noi.

Un cuvânt de precauție aici: decizia între JOINED și TABLE_PER_CLASS necesită evaluarea planurilor de execuție a interogărilor pe date reale, deoarece lățimea și adâncimea ierarhiei de moștenire pot face costul îmbinărilor (și, ca urmare, performanța) inacceptabil.

Separat, merită luat în considerare faptul că adnotările de moștenire nu pot fi aplicate interfețelor.

EXPLICIT

De asemenea, poate exista o situație în care aveți o ierarhie de clase de Entități cu o strategie de stocare partajată în baza de date. Dar, indiferent de motiv, nu doriți ca o clasă ierarhică să fie returnată atunci când se face o interogare pe clasa de bază.

Există o adnotare pentru aceasta:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Dacă îl adăugăm la clasa 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;
}

Apoi, interogările HQL vor ignora obiectele acestei clase atunci când interogând clasa de bază:

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

Această interogare va returna o listă de obiecte Utilizator și Angajat , dar nu Client .