Keterangan

Masing-masing strategi dan teknik di atas memiliki kelebihan dan kekurangannya masing-masing. Rekomendasi umum untuk memilih strategi tertentu akan terlihat seperti ini:

Strategi TABLE_PER_CLASS berdasarkan UNION

Strategi ini paling baik dipilih jika kueri dan asosiasi polimorfik tidak diperlukan. Jika Anda jarang melakukannya (atau tidak melakukannya sama sekali) "pilih pengguna dari Pengguna pengguna". Jika Anda tidak memiliki kelas Entitas yang merujuk ke Pengguna, ini adalah opsi terbaik (karena Anda masih dapat menambahkan kueri dan asosiasi polimorfik yang dioptimalkan).

SINGLE_TABLE strategi

Strategi ini harus digunakan:

a) Hanya untuk tugas-tugas sederhana. Dalam situasi di mana normalisasi dan kendala NOT NULL sangat penting, strategi #3 (BERGABUNG) harus lebih disukai. Masuk akal untuk memikirkan apakah dalam kasus ini tidak ada gunanya meninggalkan warisan sepenuhnya dan menggantinya dengan delegasi.

b) Jika kueri dan asosiasi polimorfik diperlukan, serta definisi dinamis dari kelas konkret saat dijalankan. Pada saat yang sama, subclass mendeklarasikan bidang baru yang relatif sedikit, dan perbedaan utama dengan superclass terletak pada perilakunya.

Dan di atas itu, Anda melakukan percakapan serius dengan DBA.

Strategi BERGABUNG

Strategi ini adalah yang paling efisien dalam hal kecepatan dan KENDALA. Sangat cocok dalam kasus di mana kueri dan asosiasi polimorfik diperlukan, tetapi subkelas mendeklarasikan bidang baru yang relatif banyak.

Peringatan di sini: keputusan antara JOINED dan TABLE_PER_CLASS memerlukan evaluasi rencana eksekusi kueri pada data nyata, karena lebar dan kedalaman hierarki pewarisan dapat membuat biaya penggabungan (dan, akibatnya, kinerja) tidak dapat diterima.

Secara terpisah, perlu diperhatikan bahwa anotasi pewarisan tidak dapat diterapkan ke antarmuka.

EKSPLISIT

Mungkin juga ada situasi di mana Anda memiliki hierarki kelas Entitas dengan strategi penyimpanan bersama di database. Tetapi untuk alasan apa pun, Anda tidak ingin beberapa kelas hierarki dikembalikan saat kueri dibuat di kelas dasar.

Ada anotasi untuk ini:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Jika kita menambahkannya ke kelas 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;
}

Kemudian kueri HQL akan mengabaikan objek dari kelas ini saat menanyakan kelas dasar:

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

Kueri ini akan mengembalikan daftar objek User dan Employee , tetapi bukan Client .