Ierarxiyani saqlash strategiyasini tanlash

Ta'rif

Yuqorida sanab o'tilgan strategiyalar va usullarning har biri o'zining afzalliklari va kamchiliklariga ega. Ma'lum strategiyani tanlash bo'yicha umumiy tavsiyalar quyidagicha qaraladi:

UNION asosidagi TABLE_PER_CLASS strategiyasi

Agar polimorfik so'rovlar va assotsiatsiyalar zarur bo'lmasa, ushbu strategiyani tanlash yaxshiroqdir. Agar sen kamdan-kam hollarda (yoki umuman bajarmasangiz) “select user from User user” degan so'rovlarni bajarsang. Agar sening User ga murojaat qiladigan Entity-klasslaring bo'lmasa, bu variant eng yaxshi bo'ladi (chunki optimallashtirilgan polimorf so'rovlar va assotsiatsiyalar qo'shish imkoniyati saqlanib qoladi).

SINGLE_TABLE strategiyasi

Ushbu strategiyani ishlatishga arziydi:

a) Faqatgina oddiy vazifalar uchun. Agar normallash va NOT NULL cheklovi muhim bo'lsa, 3-strategiya (JOINED) ni tanlash ma'qul. Agar bu holatda meros olishdan butunlay voz kechib, uni delegatsiya bilan almashtirish kerakmi, deb o'ylashga arziydi.

b) Agar polimorf so'rovlar va assotsiatsiyalar, shuningdek, bajarish vaqtida aniq klassni aniqlash kerak bo'lsa. Bu holatda, subklasslar nisbatan kam yangi maydonlarni e'lon qiladi va asosiy farq superklass bilan xatti-harakatda bo'ladi.

Bundan tashqari, seni BD administrator bilan jiddiy suhbat kutmoqda.

JOINED strategiyasi

Ushbu strategiya eng samarali va CONSTRAINTS tezligi bo'yicha. Bu polimorf so'rovlar va assotsiatsiyalar kerak bo'lgan hollarda mos keladi, lekin subklasslar nisbatan ko'p yangi maydonlarni e'lon qiladi.

Bu yerda e'tirof etish kerakki: JOINED va TABLE_PER_CLASS orasidagi qaror haqiqiy ma'lumotlar ustida so'rovlarni bajarish rejasini baholashni talab qiladi, chunki meros ierarxiyalarining kengligi va chuqurligi birikmalar narxini (va, natijada, samaradorlikni) qabul qilinmas qilishi mumkin.

Interfeyslarga meros annotatsiyalarini qo'llashning imkonsizligini alohida hisobga olish kerak.

EXPLICIT

Yana bir holat bo'lishi mumkin, bu holatda sening bazada saqlash strategiyasi bilan Entity-klasslar ierarxiyang mavjud. Ammo qandaydir sababga ko'ra, sen ma'lum ierarxiya klassi bazaviy klassga so'rov bo'lganda qaytishini xohlamaysan.

Buning uchun annotatsiya mavjud:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Agar biz uni Client klassiga qo'shsak:

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

HQL-so'rovlar bazaviy klassga so'rov qilinganda ushbu klassdagi obyektlarni e'tiborsiz qoldiradi:

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

Ushbu so'rov User va Employee obyektlarining ro'yxatini qaytaradi, lekin Client emas.