Memilih Strategi Pemeliharaan Hierarki

Penerangan

Setiap strategi dan teknik di atas mempunyai kelebihan dan kekurangan yang tersendiri. Cadangan am untuk memilih strategi khusus akan kelihatan seperti ini:

Strategi TABLE_PER_CLASS berdasarkan UNION

Strategi ini paling baik dipilih jika pertanyaan dan perkaitan polimorfik tidak diperlukan. Jika anda jarang melakukan (atau tidak melakukan langsung) "pilih pengguna daripada pengguna Pengguna". Jika anda tidak mempunyai sebarang kelas Entiti yang merujuk kepada Pengguna, ini ialah pilihan terbaik (kerana anda masih boleh menambah pertanyaan dan perkaitan polimorfik yang dioptimumkan).

Strategi SINGLE_TABLE

Strategi ini harus digunakan:

a) Hanya untuk tugasan mudah. Dalam situasi di mana normalisasi dan kekangan NOT NULL adalah kritikal, strategi #3 (DISERTAI) harus diutamakan. Adalah masuk akal untuk memikirkan sama ada dalam kes ini tidak patut meninggalkan warisan sepenuhnya dan menggantikannya dengan perwakilan.

b) Jika pertanyaan dan perkaitan polimorfik diperlukan, serta definisi dinamik kelas konkrit pada masa berjalan. Pada masa yang sama, subkelas mengisytiharkan agak sedikit medan baharu, dan perbezaan utama dengan superclass adalah dalam tingkah laku.

Selain itu, anda mempunyai perbualan yang serius dengan DBA.

SERTAI strategi

Strategi ini adalah yang paling cekap dari segi kelajuan dan KEKANGAN. Ia sesuai dalam kes di mana pertanyaan dan perkaitan polimorfik diperlukan, tetapi subkelas mengisytiharkan banyak medan baharu.

Satu kata berhati-hati di sini: keputusan antara JOINED dan TABLE_PER_CLASS memerlukan penilaian pelan pelaksanaan pertanyaan pada data sebenar, kerana lebar dan kedalaman hierarki warisan boleh menyebabkan kos gabungan (dan, akibatnya, prestasi) tidak boleh diterima.

Secara berasingan, adalah wajar mengambil kira bahawa anotasi warisan tidak boleh digunakan pada antara muka.

EKSPLISIT

Mungkin juga terdapat situasi di mana anda mempunyai hierarki kelas Entiti dengan strategi storan dikongsi dalam pangkalan data. Tetapi atas sebab apa pun, anda tidak mahu beberapa kelas hierarki dikembalikan apabila pertanyaan dibuat pada kelas asas.

Terdapat anotasi untuk ini:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Jika kita menambahkannya ke kelas Klien :

@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 pertanyaan HQL akan mengabaikan objek kelas ini apabila menanyakan kelas asas:

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

Pertanyaan ini akan mengembalikan senarai objek Pengguna dan Pekerja , tetapi bukan Pelanggan .