Valg af en hierarkibevarelsesstrategi

Beskrivelse

Hver af de ovennævnte strategier og teknikker har sine egne fordele og ulemper. Generelle anbefalinger til valg af en specifik strategi ser således ud:

TABLE_PER_CLASS strategi baseret på UNION

Denne strategi vælges bedst, hvis polymorfe forespørgsler og tilknytninger ikke er påkrævet. Hvis du sjældent gør (eller slet ikke gør) "vælg bruger fra brugerbruger". Hvis du ikke har Entity-klasser, der refererer til Bruger, er dette den bedste mulighed (fordi du stadig kan tilføje optimerede polymorfe forespørgsler og associationer).

SINGLE_TABLE-strategi

Denne strategi skal bruges:

a) Kun til simple opgaver. I situationer, hvor normalisering og NOT NULL-begrænsningen er kritisk, bør strategi #3 (JOINED) foretrækkes. Det giver mening at tænke over, om det i dette tilfælde ikke er værd at helt opgive arv og erstatte den med delegation.

b) Hvis polymorfe forespørgsler og associationer er påkrævet, samt dynamisk definition af en konkret klasse ved kørsel. Samtidig erklærer underklasser relativt få nye felter, og hovedforskellen med en superklasse er adfærden.

Og oven i købet har du en seriøs samtale med DBA.

TILSLUTTEDE strategi

Denne strategi er den mest effektive med hensyn til hastighed og BEGRÆNSNINGER. Det er velegnet i tilfælde, hvor polymorfe forespørgsler og associationer er påkrævet, men underklasser erklærer relativt mange nye felter.

En advarsel her: Beslutningen mellem JOINED og TABLE_PER_CLASS kræver evaluering af forespørgselsudførelsesplaner på rigtige data, da bredden og dybden af ​​arvehierarkiet kan gøre omkostningerne ved joinforbindelser (og som følge heraf ydeevne) uacceptabel.

Separat er det værd at tage i betragtning, at arvsannoteringer ikke kan anvendes på grænseflader.

EKSPLITIGT

Der kan også være en situation, hvor du har et hierarki af enhedsklasser med en delt lagringsstrategi i databasen. Men uanset årsagen vil du ikke have, at en hierarkiklasse returneres, når der laves en forespørgsel på basisklassen.

Der er en anmærkning til dette:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Hvis vi tilføjer det til klientklassen :

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

Så vil HQL-forespørgsler ignorere objekter af denne klasse, når der forespørges på basisklassen:

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

Denne forespørgsel returnerer en liste over bruger- og medarbejderobjekter , men ikke klient .