ओआरएम - डाटाबेस स्कीमा एंटिटी कंपोजिशन या वाइस वर्सा ड्राइव करता है?

Question

हमारे विकास समूह के बीच हमने काफी चर्चा की है कि क्या संस्थाओं की संरचना डेटाबेस डिज़ाइन को ड्राइव करनी चाहिए, या डेटाबेस डिज़ाइन को इकाइयों की संरचना को ड्राइव करना चाहिए।

उन लोगों के लिए जिन्होंने इसका निपटाया है, आपका दर्शन क्या रहा है? बेशक, प्रत्येक इकाई डेटाबेस तालिका में 1: 1 मानचित्र नहीं है। लेकिन, जो लोग करते हैं, उनके लिए आपने इसे कैसे संभाला है? IOW, जो पहले आता है, डेटाबेस तालिका और उसके बाद एक संबंधित इकाई या एक इकाई और फिर डेटाबेस तालिका इसे जारी रखने के लिए?

धन्यवाद।

Answer 1

आपका डेटाबेस आज जो भी एप्लिकेशन बनाता है, उससे बाहर निकल जाएगा। सभी प्रदर्शन और स्केलेबिलिटी आपके डेटाबेस स्कीमा द्वारा संचालित की जा रही हैं। एक ध्वनि डेटाबेस मॉडल वह आधार है जिस पर कोई भी एप्लिकेशन बनाया गया है, और मैं कहूंगा कि आपको डिज़ाइन और परीक्षण में सबसे अधिक प्रयास करना चाहिए, क्योंकि इससे सबसे बड़ा लाभ मिलेगा।

कहा जा रहा है कि, निश्चित रूप से आपका आवेदन डोमेन इकाइयों में हेरफेर करना पसंद करेगा, और व्यावसायिक संस्थाओं के विरोध में संबंध सिद्धांत द्वारा संचालित अप्राकृतिक संस्थाओं में हेरफेर करना, चीजों को जटिल करेगा। मेरा विचार यह है कि दो से मेल खाने के लिए ओआरएम की भूमिका है, जितना संभव हो उतना संभव है। लेकिन जब भी अपरिहार्य संघर्ष प्रकट होते हैं, तो आपके प्रदर्शन और स्केलेबिलिटी के ड्राइविंग कारक द्वारा मार्ग का अधिकार दिया जाना चाहिए: डेटाबेस स्कीमा।

Answer 2

मैं कहूंगा कि आप अपना लॉजिकल डेटा मॉडल बनाते हैं, और उसके अनुरूप डेटाबेस और ऑब्जेक्ट्स का निर्माण करते हैं।

वास्तव में, मैं इस धारणा पर सवाल उठाउंगा कि डेटाबेस तालिका और संबंधित संस्थाएं संबंधित नहीं हो सकती हैं। मैंने शायद ही कभी ऐसा मामला देखा है जहां वे वास्तव में नहीं कर सकते थे (यदि आप जमीन से आवेदन कर रहे हैं)। साथ ही, मैं कहूंगा कि ऑब्जेक्ट मॉडल और डेटाबेस स्कीमा अलग होने पर हर बार कई समस्याएं सामने आईं।

मैं इस विचार के आसपास वापस आ गया हूं कि यदि आप उन्हें हमेशा मेल खाते हैं तो सबकुछ सरल होता है, हालांकि यह हो सकता है कि यह हो सकता है।

Answer 3

"इकाई और उसके बाद एक डेटाबेस तालिका लागू करने के लिए यह"

इकाई क्या अपने कार्यक्रम manipulates है। यह संसाधित किया जा रहा है कि इसका क्या सार है।

उस इकाई का डेटाबेस प्रतिनिधित्व (जैसे फ्लैट-फ़ाइल प्रतिनिधित्व या जीयूआई प्रस्तुतिकरण) इकाई के केवल आसान प्रतिनिधित्व हैं।

आपको डीबी प्रतिनिधित्व के बारे में थोड़ा सोचना पड़ सकता है जब कुछ चीजों की बात आती है जो डेटाबेस के संबंध में विशेष रूप से खराब होते हैं। उदाहरण के लिए, कई से अधिक रिश्तों को एक अतिरिक्त तालिका शुरू करने की आवश्यकता होती है क्योंकि डेटाबेस में आपके ऑब्जेक्ट मॉडल की सीमाएं हैं। आपके पास इसका सामना करने के लिए कुछ इकाई डिज़ाइन विचार हो सकते हैं, लेकिन कुछ और अच्छी तरह से समझ गए हैं।

डेटाबेस कम महत्वपूर्ण है।

इकाई परिभाषाएं केंद्रीय और आवश्यक हैं।