सिद्धांत और प्रोपेल दोनों ऑब्जेक्ट संबंधों को मैप करने के लिए एकल और ठोस तालिका विरासत का उपयोग करते हैं। पूर्व वर्ग के पेड़ के सभी संभावित क्षेत्रों को एकल तालिका में मैप किया गया देखता है - जबकि बाद वाला प्रत्येक वर्ग को एक विशिष्ट तालिका में मैप करता है, जो वंशानुगत पदानुक्रम में सामान्य क्षेत्रों की नकल करता है।
जबकि यह ORM उपकरण की सुविधा देता है, यह मुझे खराब डेटाबेस डिजाइन का सुझाव देता है। क्या ये खराब डिज़ाइन पैटर्न डेटाबेस पर लागू करने के लिए हैं?
जवाबों:
यह कहना असंभव है कि क्या एक विशेष डेटाबेस डिजाइन यह जानने के बिना खराब है कि आवेदन क्या कर रहा है, डेटा का आकार, प्रदर्शन अपेक्षाएं और इतने पर। हालांकि आम तौर पर सामान्यीकरण (कुछ हद तक) को सर्वश्रेष्ठ अभ्यास के रूप में देखा जाता है, प्रदर्शन के कारणों के लिए डेटाबेस के क्षेत्रों को निरूपित करना बहुत आम बात है, क्योंकि अच्छे और बुरे बहुत अधिक डेटा के बिना चर्चा के लिए बहुत अधिक खुले हैं, जब अधिकांश लोग बाहर शुरू करते हैं।
कई दृष्टिकोणों में जोड़ें, जो संबंधपरक मैपिंग के लिए ऑब्जेक्ट पर ले जा सकते हैं और चीजें और भी जटिल हो जाती हैं क्योंकि "सर्वश्रेष्ठ" डेटाबेस संरचना विशिष्ट ऑब्जेक्ट मॉडल, विरासत के स्तर और इतने पर निर्भर करेगी।
एक आकार लेने से सभी दृष्टिकोण फिट बैठता है ORM दृढ़ता पुस्तकालय हमेशा किसी भी स्थिति के लिए एक गैर-इष्टतम डेटाबेस संरचना का उत्पादन करेगा और कुछ चीजों का उपयोग करेगा जो कि किसी दिए गए स्थिति के लिए बुरे अभ्यास के रूप में देखा जा सकता है ।
आप निश्चित रूप से एक ORM लिख सकते हैं जो सामान्यीकृत है, लेकिन आप प्रत्येक मुख्य तालिका में सम्मिलित करने के लिए काफी विषम प्रदर्शन निहितार्थ देखेंगे, यह देखने के लिए कि क्या उनकी कुंजी प्राप्त हुई और यदि उन्होंने नहीं किया, तो यह देखने के लिए विभिन्न लुक टेबल को स्कैन करने की आवश्यकता है। 'प्रासंगिक आवेषण बाहर ले जाने के लिए नहीं है।
(जब आप इसे हाथ से करते हैं, तो आप इनमें से कुछ को काट सकते हैं, जैसा कि आप जानते हैं कि आपने उन्हें केवल वैध मान वाले एक ड्रॉप डाउन के साथ प्रस्तुत किया है, इसलिए आपको इन लुक अप को करने की आवश्यकता नहीं है, आप बस उस खुश खुश कुंजी का उपयोग कर सकते हैं जो यह जा रहा है मान्य होने के लिए, ORM उस धारणा को नहीं बना सकता क्योंकि यह UI को नियंत्रित नहीं करता है।]
लेकिन आपको याद रखना होगा कि वे डेटाबेस प्रदर्शन या डेटा अखंडता के लिए अनुकूलन करने का लक्ष्य नहीं रखते हैं, वे विकास की गति के लिए अनुकूलन कर रहे हैं । यदि आपके डेटा की विशिष्ट संरचना आपके लिए महत्वपूर्ण है, तो आपको या तो अपने ऑब्जेक्ट / RDBMS मैपिंग को हाथ से कोड करने की आवश्यकता है, या बहुत कम से कम उपलब्ध सभी पुस्तकालयों का विस्तृत मूल्यांकन करें और उस का चयन करें जो आपकी आवश्यकताओं को सबसे करीब से पूरा करता है ( अगर कोई मौजूद है)।
अनिवार्य रूप से यह आवश्यकताओं के लिए नीचे आता है और अच्छी तरह से संरचित डेटा, डेटाबेस प्रदर्शन और विकास की गति के बीच व्यापार बंद हो जाता है। कई ट्रेड-ऑफ के साथ आपको तीनों लेने के लिए नहीं मिलते हैं।
मैं इस बात से सहमत नहीं हूं कि ORM डी-सामान्यकरण या खराब डेटाबेस डिजाइन को बढ़ावा देता है। वास्तव में, मैंने जो सबसे खराब डिजाइनिंग डेटाबेस देखा है, वह ओआरएम के बिना किया गया है। एक यादृच्छिक क्षेत्र के मूल्य के आधार पर संबंध बनाने के बजाय पंक्ति आईडी के आधार पर उचित संबंध बनाने को सरल बनाने से, यह डेटाबेस डेटाबेस डिजाइन को बढ़ावा देता है।
संभवतः यह सामान्यीकरण को बढ़ावा नहीं देता है, लेकिन फिर एक ORM है जहां टेबल / ऑब्जेक्ट बनाना आसान है और संबंधों को बढ़ावा देने के लिए लगभग देखा जा सकता है। ओआरएम में कर्मचारियों की तालिका में पते को जोड़ने के बजाय पते के साथ "स्थान" तालिका बनाने और कर्मचारियों को स्थान से जोड़ने के लिए यह अधिक काम नहीं है। लेकिन ओआरएम के बिना, स्थान को अलग करने का मतलब है कि हर बार जब आप स्थान तक पहुंचना चाहते हैं, तो आपको जुड़ने की आवश्यकता है।
तो मेरा जवाब है: नहीं, मुझे ऐसा नहीं लगता । यह संभवतः अन्य अन्य तरीकों से संभव है, एक अच्छा ओआरएम अच्छा डेटाबेस डिजाइन को प्रोत्साहित करता है , कम से कम उन लोगों के बारे में जिनके पास थोड़ा अनुभव है।