ORM में लिंक लोड करने के लिए एक बड़े के बजाय कुछ सरल प्रश्न

मैं तुरंत आरक्षण करूँगा, यह एक प्रशिक्षण पद या किसी नए प्रतिमान की घोषणा नहीं है)), यह मेरे द्वारा लिया गया निर्णय है, और मैं इस पर विस्तृत और ईमानदार चर्चा करना चाहता हूं।
अब इस बिंदु पर, कल्पना करें कि PHP में किसी प्रकार का ORM लिखा गया है, जो पोस्ट मॉडल का वर्णन करता है, जिसमें अन्य मॉडलों के साथ मध्यवर्ती तालिकाओं के माध्यम से कई-से-कई संबंध हैं: टिप्पणियाँ, टैग, श्रेणियाँ । सवाल यह है कि संबंधित डेटा जुटाने का सबसे अच्छा तरीका क्या है, एक बार में या लोडिंग में देरी के साथ?

डेटाबेस समुदाय में प्रचलित राय यह है कि join'ov के एक समूह के साथ एकल अनुरोध के साथ डेटा चुनना बेहतर है, वे कहते हैं कि DBMS स्मार्ट है, यह पता लगाएगा कि यह सबसे तेज़ और कम डेटाबेस कैसे बेहतर होता है। मेरे अभ्यास में, ऐसे मामले थे जब बड़े तालिकाओं वाली उच्च-लोड वाली परियोजनाओं पर, कई सरल प्रश्नों ने एक साथ कई बड़े जोड़ के साथ तेजी से काम किया।
ओआरएम की ओर से, सभी डेटा को एक अनुरोध के साथ उठाना भी सबसे अच्छा विकल्प नहीं है, क्योंकि, लगभग हमेशा, अतिरिक्त डेटा उठाया जाएगा जो इस जगह की आवश्यकता नहीं है (या यहां तक ​​कि हस्तक्षेप भी कर सकता है, और फिर उन्हें अभी भी सेट से हटा दिया जाना है), या आपको एक सेट करने की आवश्यकता है FindWithComments, findWithCategoriesAndTags जैसे तरीके, अपरिहार्य दोहराव के साथ findWithAllRelations।
इस प्रकार, हमारे पास लिंक (मॉडल विधियाँ) लोड करने के तीन तरीके हैं:

• एक खोज ($ आईडी) विधि जो हमेशा एक ही अनुरोध में सभी डेटा को लोड करती है।
• कई तरीके ($ id), findWithComments ($ id), findWithTagsAndCategories ($ id) ...
• खोज ($ id) विधि, जो लिंक getComments (), getTags () लोड करने के लिए केवल वर्तमान मॉडल + स्पष्ट विधियों को लोड करती है ... बाद वाली विधियों के साथ दोनों एक ही वस्तु और वस्तुओं के संग्रह (समग्र के समान) के लिए समान काम करती हैं।

यदि हम किसी प्रकार के सार्वभौमिक ओआरएम को डिजाइन करने के बारे में बात करते हैं, तो बाद वाला विकल्प मुझे अधिक सही लगता है, और ओआरएम को दूसरे दृष्टिकोण की अनुमति नहीं देनी चाहिए। मैं लाभों के बारे में बात करूंगा।

• डीबी स्तर पर कैशिंग। बड़े अनूठे अनुरोधों की तुलना में डेटा का छोटा हिस्सा अधिक बार (अलग-अलग अनुरोधों में उनके पुन: उपयोग के कारण) कैश से लिया जाना चाहिए।
• आवेदन स्तर कैशिंग। एक नियम के रूप में, विभिन्न तालिकाओं के डेटा में क्षय की अलग-अलग दरें हैं, यदि आप पहली विधि का उपयोग करते हैं, तो आपको डेटा पर ध्यान केंद्रित करना होगा जो सबसे जल्दी अप्रासंगिक हो जाता है। यदि आप तीसरी विधि का उपयोग करते हैं, तो प्रत्येक मॉडल के लिए आप अपने स्वयं के कैश जीवनकाल को निर्दिष्ट कर सकते हैं, इसके अलावा यह कैश (घटना या मैन्युअल रूप से) को साफ़ करने का अधिक लचीला (मॉडल-आधारित) नियंत्रण देता है।
• डेटा वॉल्यूम की वृद्धि या प्रश्नों की संख्या के साथ, हमारे पास वर्टिकल डेटाबेस शार्किंग के लिए तैयार आर्किटेक्चर है।
• प्रत्येक मामले में, हम केवल उस डेटा को डाउनलोड कर सकते हैं जिसकी हमें आवश्यकता है।
• SQL और noSQL के मिश्रित उपयोग के लिए तैयार वास्तुकला, उदाहरण के लिए, हम कुछ मॉडल को मूंगो या रेडिस में स्थानांतरित कर सकते हैं, इसके लिए पूर्व निर्धारित संख्या को फिर से लिख सकते हैं।

मॉडल के इस तरह के कठोर अलगाव का कमजोर बिंदु यह है कि कई मानदंडों द्वारा तुरंत एक लचीली खोज कैसे की जाए, उदाहरण के लिए, टैग और श्रेणियों द्वारा पोस्ट।
सामान्य तौर पर, मैं आपको चर्चा के लिए आमंत्रित करता हूं, ऐसे अन्य नुकसान क्या हैं, शायद कोई व्यक्ति इस तरह के निर्णय से आया / गया है, क्या आप अपनी परियोजनाओं में इस तरह के ओआरएम का उपयोग करेंगे?