Bir Hiyerarşi Koruma Stratejisi Seçme

Tanım

Yukarıdaki strateji ve tekniklerin her birinin kendi avantajları ve dezavantajları vardır. Belirli bir strateji seçmek için genel öneriler şöyle görünecektir:

UNION tabanlı TABLE_PER_CLASS stratejisi

Bu strateji, polimorfik sorgular ve ilişkilendirmeler gerekli değilse en iyi şekilde seçilir. Nadiren yaparsanız (veya hiç yapmazsanız) "Kullanıcı kullanıcıdan kullanıcı seçin". Kullanıcıya atıfta bulunan herhangi bir Varlık sınıfınız yoksa, bu en iyi seçenektir (yine de optimize edilmiş polimorfik sorgular ve ilişkilendirmeler ekleyebileceğiniz için).

SINGLE_TABLE stratejisi

Bu strateji kullanılmalıdır:

a) Yalnızca basit görevler için. Normalleştirme ve NOT NULL kısıtlamasının kritik olduğu durumlarda strateji #3 (JOINED) tercih edilmelidir. Bu durumda mirası tamamen terk etmeye ve onu delegasyonla değiştirmeye değip değmeyeceğini düşünmek mantıklıdır.

b) Çalışma zamanında somut bir sınıfın dinamik tanımının yanı sıra polimorfik sorgular ve ilişkilendirmeler gerekiyorsa. Aynı zamanda, alt sınıflar nispeten az sayıda yeni alan bildirir ve bir üst sınıftan temel fark davranıştır.

Üstelik DBA ile ciddi bir görüşmeniz var.

BİRLEŞTİRİLMİŞ strateji

Bu strateji, hız ve KISITLAMALAR açısından en verimli olanıdır. Polimorfik sorguların ve ilişkilendirmelerin gerekli olduğu, ancak alt sınıfların nispeten birçok yeni alan bildirdiği durumlarda uygundur.

Burada bir uyarı: kalıtım hiyerarşisinin genişliği ve derinliği birleştirmelerin maliyetini (ve sonuç olarak performansı) kabul edilemez hale getirebileceğinden, JOINED ve TABLE_PER_CLASS arasındaki karar, gerçek veriler üzerinde sorgu yürütme planlarının değerlendirilmesini gerektirir.

Ayrı olarak, kalıtım ek açıklamalarının arayüzlere uygulanamayacağını dikkate almakta fayda var.

AÇIK

Veritabanında paylaşılan bir depolama stratejisine sahip bir Entity sınıfları hiyerarşisine sahip olduğunuz bir durum da olabilir. Ancak her ne sebeple olursa olsun, temel sınıfta bir sorgu yapıldığında bazı hiyerarşi sınıflarının döndürülmesini istemezsiniz.

Bunun için bir açıklama var:

@Polymorphism(type = PolymorphismType.EXPLICIT)

Bunu Client sınıfına eklersek :

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

Ardından HQL sorguları, temel sınıfı sorgularken bu sınıfın nesnelerini yok sayar:

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

Bu sorgu, Kullanıcı ve Çalışan nesnelerinin bir listesini döndürür , ancak İstemciyi döndürmez .