Velge en hierarkibevaringsstrategi

Beskrivelse

Hver av de ovennevnte strategiene og teknikkene har sine egne fordeler og ulemper. Generelle anbefalinger for å velge en spesifikk strategi vil se slik ut:

TABLE_PER_CLASS-strategi basert på UNION

Denne strategien er best valgt hvis polymorfe spørringer og assosiasjoner ikke er nødvendig. Hvis du sjelden gjør (eller ikke gjør det i det hele tatt) "velg bruker fra brukerbruker". Hvis du ikke har Entity-klasser som refererer til Bruker, er dette det beste alternativet (fordi du fortsatt kan legge til optimaliserte polymorfe spørringer og assosiasjoner).

SINGLE_TABLE-strategi

Denne strategien bør brukes:

a) Kun for enkle oppgaver. I situasjoner der normalisering og NOT NULL-begrensningen er kritiske, bør strategi #3 (SAMMENFATTET) foretrekkes. Det er fornuftig å tenke på om det i dette tilfellet ikke er verdt å helt forlate arv og erstatte den med delegering.

b) Hvis polymorfe spørringer og assosiasjoner kreves, samt dynamisk definisjon av en konkret klasse ved kjøring. Samtidig erklærer underklasser relativt få nye felt, og hovedforskjellen med en superklasse er atferd.

Og på toppen av det har du en seriøs samtale med DBA.

BLITT MED strategi

Denne strategien er den mest effektive når det gjelder hastighet og BEGRENSNINGER. Det er egnet i tilfeller der polymorfe spørringer og assosiasjoner kreves, men underklasser erklærer relativt mange nye felt.

Et ord med forsiktighet her: avgjørelsen mellom JOINED og TABLE_PER_CLASS krever evaluering av spørringsutførelsesplaner på ekte data, siden bredden og dybden av arvehierarkiet kan gjøre kostnadene for sammenføyninger (og som et resultat av ytelsen) uakseptable.

Separat er det verdt å ta hensyn til at arvemerknader ikke kan brukes på grensesnitt.

EKSPLISITT

Det kan også være en situasjon der du har et hierarki av Entity-klasser med en delt lagringsstrategi i databasen. Men uansett grunn, vil du ikke at noen hierarkiklasse skal returneres når en spørring blir gjort på basisklassen.

Det er en merknad for dette:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Hvis vi legger 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;
}

Da vil HQL-spørringer ignorere objekter av denne klassen når de spør etter basisklassen:

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

Denne spørringen vil returnere en liste over bruker- og ansattobjekter , men ikke klient .