पदानुक्रम संरक्षण धोरण निवडणे

वर्णन

वरील प्रत्येक रणनीती आणि तंत्राचे स्वतःचे फायदे आणि तोटे आहेत. विशिष्ट धोरण निवडण्यासाठी सामान्य शिफारसी यासारखे दिसतील:

UNION वर आधारित TABLE_PER_CLASS धोरण

पॉलिमॉर्फिक क्वेरी आणि असोसिएशन आवश्यक नसल्यास ही रणनीती सर्वोत्तम निवडली जाते. तुम्ही क्वचितच करत असल्यास (किंवा अजिबात करत नाही) "वापरकर्ता वापरकर्त्याकडून वापरकर्ता निवडा". तुमच्याकडे वापरकर्त्याचा संदर्भ देणारे घटक वर्ग नसल्यास, हा सर्वोत्तम पर्याय आहे (कारण तुम्ही तरीही ऑप्टिमाइझ केलेल्या पॉलिमॉर्फिक क्वेरी आणि असोसिएशन जोडू शकता).

SINGLE_TABLE धोरण

हे धोरण वापरले पाहिजे:

अ) फक्त साध्या कामांसाठी. ज्या परिस्थितीत सामान्यीकरण आणि शून्य नसलेले बंधन गंभीर आहे, धोरण #3 (जॉइन केलेले) प्राधान्य दिले पाहिजे. या प्रकरणात वारसा पूर्णपणे सोडून देणे आणि त्यास प्रतिनिधी मंडळाने बदलणे योग्य नाही का याचा विचार करणे अर्थपूर्ण आहे.

b) जर बहुरूपी क्वेरी आणि असोसिएशन आवश्यक असतील, तसेच रन टाइममध्ये ठोस वर्गाची डायनॅमिक व्याख्या. त्याच वेळी, उपवर्ग तुलनेने काही नवीन फील्ड घोषित करतात आणि सुपरक्लाससह मुख्य फरक वर्तनात आहे.

आणि त्या वर, आपण DBA सह गंभीर संभाषण केले आहे.

सामील झाले धोरण

ही रणनीती वेग आणि बंधनांच्या बाबतीत सर्वात कार्यक्षम आहे. हे अशा प्रकरणांमध्ये योग्य आहे जेथे बहुरूपी क्वेरी आणि असोसिएशन आवश्यक आहेत, परंतु उपवर्ग तुलनेने अनेक नवीन फील्ड घोषित करतात.

येथे सावधगिरीचा एक शब्द: JOINED आणि TABLE_PER_CLASS मधील निर्णयासाठी वास्तविक डेटावर क्वेरी अंमलबजावणी योजनांचे मूल्यमापन आवश्यक आहे, कारण वारसा पदानुक्रमाची रुंदी आणि खोली जोडणीची किंमत (आणि परिणामी, कार्यप्रदर्शन) अस्वीकार्य बनवू शकते.

स्वतंत्रपणे, हे लक्षात घेण्यासारखे आहे की इंटरफेसवर वारसा भाष्य लागू केले जाऊ शकत नाही.

स्पष्ट

अशी परिस्थिती देखील असू शकते जेव्हा तुमच्याकडे डेटाबेसमध्ये सामायिक स्टोरेज धोरणासह घटक वर्गांची श्रेणीक्रम असेल. परंतु कोणत्याही कारणास्तव, जेव्हा बेस क्लासवर क्वेरी केली जाते तेव्हा तुम्हाला काही पदानुक्रम वर्ग परत मिळू इच्छित नाही.

यासाठी एक भाष्य आहे:

@Polymorphism(type = PolymorphismType.EXPLICIT)

जर आपण ते क्लायंट क्लासमध्ये जोडले तर :

@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 क्वेरी या क्लासच्या ऑब्जेक्ट्सकडे दुर्लक्ष करतील:

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

ही क्वेरी वापरकर्ता आणि कर्मचारी वस्तूंची सूची देईल , परंतु क्लायंटची नाही .