Scelta di una strategia di conservazione della gerarchia

Descrizione

Ognuna delle strategie e delle tecniche di cui sopra ha i suoi vantaggi e svantaggi. Le raccomandazioni generali per la scelta di una strategia specifica saranno simili a queste:

Strategia TABLE_PER_CLASS basata su UNION

Questa strategia è la scelta migliore se non sono necessarie query e associazioni polimorfiche. Se lo fai raramente (o non lo fai affatto) "seleziona utente da Utente utente". Se non disponi di classi di entità che fanno riferimento a User, questa è l'opzione migliore (poiché puoi ancora aggiungere query e associazioni polimorfiche ottimizzate).

Strategia SINGLE_TABLE

Questa strategia dovrebbe essere utilizzata:

a) Solo per compiti semplici. In situazioni in cui la normalizzazione e il vincolo NOT NULL sono critici, dovrebbe essere preferita la strategia n. 3 (JOINED). Ha senso pensare se in questo caso non valga la pena abbandonare completamente l'eredità e sostituirla con la delega.

b) Se sono necessarie query e associazioni polimorfiche, nonché definizione dinamica di una classe concreta in fase di esecuzione. Allo stesso tempo, le sottoclassi dichiarano relativamente pochi nuovi campi e la principale differenza con una superclasse è nel comportamento.

E per di più, hai una conversazione seria con il DBA.

Strategia CONGIUNTA

Questa strategia è la più efficiente in termini di velocità e VINCOLI. È adatto nei casi in cui sono richieste query e associazioni polimorfiche, ma le sottoclassi dichiarano relativamente molti nuovi campi.

Un avvertimento qui: la decisione tra JOINED e TABLE_PER_CLASS richiede la valutazione dei piani di esecuzione della query su dati reali, poiché l'ampiezza e la profondità della gerarchia di ereditarietà possono rendere inaccettabile il costo dei join (e, di conseguenza, le prestazioni).

Separatamente, vale la pena tenere conto del fatto che le annotazioni di ereditarietà non possono essere applicate alle interfacce.

ESPLICITO

Potrebbe anche verificarsi una situazione in cui si dispone di una gerarchia di classi Entity con una strategia di archiviazione condivisa nel database. Ma per qualsiasi motivo, non vuoi che venga restituita una classe gerarchica quando viene eseguita una query sulla classe base.

C'è un'annotazione per questo:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Se lo aggiungiamo alla classe 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;
}

Quindi le query HQL ignoreranno gli oggetti di questa classe durante l'interrogazione della classe base:

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

Questa query restituirà un elenco di oggetti User e Employee , ma non Client .