Pagpili ng Hierarchy Preservation Strategy

Paglalarawan

Ang bawat isa sa mga diskarte at pamamaraan sa itaas ay may sariling mga pakinabang at disadvantages. Ang mga pangkalahatang rekomendasyon para sa pagpili ng isang partikular na diskarte ay magiging ganito:

TABLE_PER_CLASS na diskarte batay sa UNION

Ang diskarte na ito ay pinakamahusay na pinili kung polymorphic query at asosasyon ay hindi kinakailangan. Kung bihira mong gawin (o hindi mo gawin) "pumili ng user mula sa User user". Kung wala kang mga klase ng Entity na tumutukoy sa User, ito ang pinakamagandang opsyon (dahil maaari ka pa ring magdagdag ng mga naka-optimize na polymorphic na query at asosasyon).

SINGLE_TABLE na diskarte

Ang diskarte na ito ay dapat gamitin:

a) Para lamang sa mga simpleng gawain. Sa mga sitwasyon kung saan ang normalisasyon at ang NOT NULL constraint ay kritikal, ang diskarte #3 (JOINED) ay dapat na mas gusto. Makatuwirang isipin kung sa kasong ito ay hindi sulit na ganap na iwanan ang mana at palitan ito ng delegasyon.

b) Kung kinakailangan ang polymorphic na mga query at asosasyon, pati na rin ang dynamic na kahulugan ng isang kongkretong klase sa oras ng pagtakbo. Kasabay nito, ang mga subclass ay nagdeklara ng medyo kaunting mga bagong field, at ang pangunahing pagkakaiba sa isang superclass ay sa pag-uugali.

At higit pa rito, mayroon kang seryosong pag-uusap sa DBA.

SUMALI sa diskarte

Ang diskarte na ito ay ang pinaka-epektibo sa mga tuntunin ng bilis at PAGHAHITA. Ito ay angkop sa mga kaso kung saan kinakailangan ang mga polymorphic na query at asosasyon, ngunit ang mga subclass ay nagdeklara ng medyo maraming bagong field.

Isang salita ng pag-iingat dito: ang desisyon sa pagitan ng JOINED at TABLE_PER_CLASS ay nangangailangan ng pagsusuri ng mga plano sa pagpapatupad ng query sa totoong data, dahil ang lapad at lalim ng hierarchy ng mana ay maaaring gawing hindi katanggap-tanggap ang halaga ng mga pagsali (at, bilang resulta, pagganap).

Hiwalay, ito ay nagkakahalaga ng pagsasaalang-alang na ang inheritance annotation ay hindi mailalapat sa mga interface.

TAHASANG

Maaaring mayroon ding sitwasyon kung saan mayroon kang hierarchy ng mga klase ng Entity na may nakabahaging diskarte sa storage sa database. Ngunit sa anumang dahilan, hindi mo gustong maibalik ang ilang hierarchy class kapag may ginawang query sa base class.

Mayroong annotation para dito:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Kung idaragdag natin ito sa klase ng Kliyente :

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

Pagkatapos ay babalewalain ng mga query ng HQL ang mga bagay ng klase na ito kapag nagtatanong sa batayang klase:

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

Ang query na ito ay magbabalik ng isang listahan ng mga bagay ng User at Empleyado , ngunit hindi ang Client .