एक पदानुक्रम संरक्षण रणनीति चुनना

विवरण

उपरोक्त रणनीतियों और तकनीकों में से प्रत्येक के अपने फायदे और नुकसान हैं। विशिष्ट रणनीति चुनने के लिए सामान्य सिफारिशें इस तरह दिखेंगी:

UNION पर आधारित TABLE_PER_CLASS रणनीति

बहुरूपी प्रश्नों और संघों की आवश्यकता नहीं होने पर यह रणनीति सबसे अच्छी तरह से चुनी जाती है। यदि आप शायद ही कभी करते हैं (या बिल्कुल नहीं करते हैं) "उपयोगकर्ता उपयोगकर्ता से उपयोगकर्ता का चयन करें"। यदि आपके पास उपयोगकर्ता को संदर्भित करने वाली इकाई कक्षाएं नहीं हैं, तो यह सबसे अच्छा विकल्प है (क्योंकि आप अभी भी अनुकूलित बहुरूपी प्रश्नों और संघों को जोड़ सकते हैं)।

SINGLE_TABLE रणनीति

इस रणनीति का इस्तेमाल किया जाना चाहिए:

a) केवल साधारण कार्यों के लिए। ऐसी परिस्थितियों में जहां सामान्यीकरण और नॉट न्यूल बाधा महत्वपूर्ण हैं, रणनीति #3 (जॉइन) को प्राथमिकता दी जानी चाहिए। यह सोचने के लिए समझ में आता है कि क्या इस मामले में यह विरासत को पूरी तरह से त्यागने और इसे प्रतिनिधिमंडल के साथ बदलने के लायक नहीं है।

बी) यदि बहुरूपी प्रश्नों और संघों की आवश्यकता होती है, साथ ही साथ रन टाइम पर एक ठोस वर्ग की गतिशील परिभाषा। इसी समय, उपवर्ग अपेक्षाकृत कुछ नए क्षेत्रों की घोषणा करते हैं, और सुपरक्लास के साथ मुख्य अंतर व्यवहार में है।

और उसके शीर्ष पर, आपकी 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;
}

फिर बेस क्लास से पूछताछ करते समय एचक्यूएल प्रश्न इस वर्ग की वस्तुओं को अनदेखा कर देंगे:

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

यह क्वेरी User और Employee ऑब्जेक्ट्स की सूची देगी , लेकिन Client नहीं ।