Hierarchia megőrzési stratégia kiválasztása

Leírás

A fenti stratégiák és technikák mindegyikének megvannak a maga előnyei és hátrányai. Egy adott stratégia kiválasztására vonatkozó általános ajánlások így néznek ki:

TABLE_PER_CLASS stratégia az UNION alapján

Ezt a stratégiát a legjobb akkor választani, ha nincs szükség polimorf lekérdezésekre és asszociációkra. Ha ritkán teszed (vagy egyáltalán nem) "felhasználót válassz a Felhasználó felhasználó közül". Ha nem rendelkezik olyan entitásosztályokkal, amelyek a User-re hivatkoznak, ez a legjobb megoldás (mivel továbbra is hozzáadhat optimalizált polimorf lekérdezéseket és asszociációkat).

SINGLE_TABLE stratégia

Ezt a stratégiát kell használni:

a) Csak egyszerű feladatokhoz. Olyan helyzetekben, amikor a normalizálás és a NOT NULL megkötés kritikus, a 3. (JOINED) stratégiát kell előnyben részesíteni. Érdemes elgondolkodni azon, hogy ebben az esetben nem érdemes-e teljesen lemondani az öröklésről, és delegálással helyettesíteni.

b) Ha polimorf lekérdezések és asszociációk szükségesek, valamint egy konkrét osztály dinamikus meghatározása futás közben. Ugyanakkor az alosztályok viszonylag kevés új mezőt deklarálnak, és a fő különbség a szuperosztályokkal szemben a viselkedésben van.

És ráadásul komoly beszélgetést folytat a DBA-val.

JOINED stratégia

Ez a stratégia a leghatékonyabb a sebesség és a KORLÁTOZÁSOK szempontjából. Alkalmas olyan esetekben, amikor polimorf lekérdezésekre és asszociációkra van szükség, de az alosztályok viszonylag sok új mezőt deklarálnak.

Figyelmeztetés: a JOINED és a TABLE_PER_CLASS közötti döntés megköveteli a lekérdezés-végrehajtási tervek kiértékelését valós adatokon, mivel az öröklődési hierarchia szélessége és mélysége elfogadhatatlanná teheti az összekapcsolások költségeit (és ennek eredményeként a teljesítményt).

Külön érdemes figyelembe venni, hogy az öröklési annotációkat nem lehet interfészekre alkalmazni.

KIFEJEZETT

Előfordulhat olyan helyzet is, amikor az adatbázisban megosztott tárolási stratégiával rendelkező entitásosztályok hierarchiája van. De bármilyen okból kifolyólag nem akarja, hogy valamilyen hierarchiaosztály adjon vissza, amikor lekérdezés történik az alaposztályon.

Ehhez van egy megjegyzés:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Ha hozzáadjuk a Client osztályhoz :

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

Ekkor a HQL lekérdezések figyelmen kívül hagyják ennek az osztálynak az objektumait az alaposztály lekérdezésekor:

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

Ez a lekérdezés a Felhasználó és az Alkalmazott objektumok listáját adja vissza , de az Ügyfelet nem .