Избор на стратегия за запазване на йерархията

Описание

Всяка от горните стратегии и техники има своите предимства и недостатъци. Общите препоръки за избор на конкретна стратегия ще изглеждат така:

Стратегия TABLE_PER_CLASS, базирана на UNION

Тази стратегия е най-добре избрана, ако не се изискват полиморфни заявки и асоциации. Ако рядко правите (or изобщо не правите) „изберете потребител от потребителски потребител“. Ако нямате класове Entity, които се отнасят до User, това е най-добрият вариант (защото все още можете да добавяте оптимизирани полиморфни заявки и асоциации).

Стратегия SINGLE_TABLE

Тази стратегия трябва да се използва:

а) Само за прости задачи. В ситуации, в които нормализацията и ограничението NOT NULL са критични, трябва да се предпочита стратегия #3 (JOINED). Има смисъл да помислим дали в този случай не си струва напълно да изоставим наследството и да го заменим с делегиране.

b) Ако се изискват полиморфни заявки и асоциации, Howто и динамична дефиниция на конкретен клас по време на изпълнение. В същото време подкласовете декларират относително малко нови полета и основната разлика със суперкласа е в поведението.

И на всичкото отгоре имаш сериозен разговор с DBA.

СЪЕДИНЕНА стратегия

Тази стратегия е най-ефективната от гледна точка на скорост и ОГРАНИЧЕНИЯ. Подходящо е в случаите, когато се изискват полиморфни заявки и асоциации, но подкласовете декларират относително много нови полета.

Дума на предпазливост тук: решението между JOINED и TABLE_PER_CLASS изисква оценка на плановете за изпълнение на заявката върху реални данни, тъй като ширината и дълбочината на йерархията на наследяване може да направи цената на присъединяването (и, като резултат, производителността) неприемлива.

Отделно, струва си да се има предвид, че анотациите за наследяване не могат да се прилагат към интерфейси.

ИЗРИЧЕН

Може да има и ситуация, в която имате йерархия от класове на обекти със споделена стратегия за съхранение в базата данни. Но по няHowва причина не искате няHowъв йерархичен клас да бъде върнат, когато се направи заявка към основния клас.

Има анотация за това:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Ако го добавим към класа 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;
}

Тогава HQL заявките ще игнорират обекти от този клас, когато заявяват базовия клас:

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

Тази заявка ще върне списък с обекти User и Employee , но не и Client .