ORM, CodeFirst पर आधारित डेटाबेस के साथ इसके फायदे और नुकसान के साथ काम करने के लिए अवधारणाएं हैं। यहाँ प्रस्तावित आधार एकीकरण मुख्य रूप से डेटाबेस प्रथम दृष्टिकोण पर आधारित है।
एक जटिल डोमेन मॉडल (जिसमें ईआरपी सिस्टम शामिल है) के साथ एक एप्लिकेशन डेटाबेस स्कीमा आमतौर पर होता है
कई सौ टेबल।
इसलिए, आधार को डिजाइन करने के प्रारंभिक चरण में, सर्किट के दोहराया दोहराव और सूजन से बचना महत्वपूर्ण है
एप्लिकेशन की मूल संस्थाओं के सामान्य गुणों को संग्रहीत करने के लिए कई बेस टेबल पर निर्णय लें
और अन्य सभी तालिकाओं को पहले से ही मुख्य तालिकाओं के सहायक या परिवर्धन के रूप में डिज़ाइन किया गया है।
दस्तावेज़ डिजाइन करने का एक उदाहरण:
- सभी दस्तावेजों के सामान्य गुणों को एक अलग तालिका में रखा गया है।
- अपने स्वयं के विशिष्ट क्षेत्रों के साथ प्रत्येक प्रकार के दस्तावेज़ के लिए एक अलग तालिका बनाई गई है।
सामान्य तालिका में शामिल होता है। एक सामान्य तालिका में एफके सूचकांक क्षेत्रों की संख्या को कम करने के लिए, पीके करें। दस्तावेजों की एक सूची प्रदर्शित करते समय, हम आधार तालिका से केवल सामान्य फ़ील्ड प्रदर्शित करते हैं, और एक विशिष्ट दस्तावेज़ प्रदर्शित करते समय हम पहले से ही उपयोग करते हैं, इसलिए, प्रदर्शन को नुकसान नहीं होता है।
- आमतौर पर समान दस्तावेज़ फ़ील्ड (विशेषकर यदि वे विभिन्न प्रकार के दस्तावेज़ों के लिए भिन्न होते हैं) को अलग-अलग सामान्य तालिकाओं में रखा जाता है। यह है
- समकक्षों के संदर्भ (उदाहरण के लिए, एक अदालत, एक शिकायतकर्ता, एक इच्छुक पार्टी, दस्तावेज़ के लिए एक तीसरी पार्टी "शिकायत पर प्रतिक्रिया)।
- दस्तावेज़ में कुछ भूमिका निभा रहे लोगों के लिए लिंक (लेखक, प्राप्तकर्ता, कलाकार,
समन्वय, जिम्मेदार, क्लर्क, प्रबंधक)।
- अन्य दस्तावेजों (आधार, यात्रा दस्तावेज, अनुबंध, खाता, असहमति के प्रोटोकॉल, अनुबंध) का संदर्भ।
हम इन तालिकाओं को एक फ़ील्ड - लिंक के प्रकार (PostgreSQL के लिए - एनम उपयुक्त है) के साथ पूरक करते हैं। इस अनुरोध में
एक निश्चित दस्तावेज़ जॉइन्स से घिरा हुआ है, लेकिन डेटा हैंडलिंग को एकीकृत करने में लाभ बहुत बड़ा है:
किसी दस्तावेज़ को हटाते समय, किसी दस्तावेज़ को सहेजते समय, सामान्य तालिकाओं के सभी क्षेत्रों के लिए दस्तावेज़ की प्रतिलिपि बनाते हुए जाँचना विशेष रूप से सैकड़ों प्रकार के दस्तावेज़ों के लिए नहीं, बल्कि एक बार किया जाएगा।
साथ ही, हमारे पास एक दस्तावेज़ के लिए कई लिंक (कई प्राप्तकर्ता, अनुबंध, तीसरे पक्ष) के अवसर हैं।
- इसके अलावा, प्रत्येक ईआरपी सबसिस्टम (बजट, लॉजिस्टिक्स, ईडीएस, वेयरहाउस, सीआरएम, ..) के समान सामान्य गुणों के साथ अपने स्वयं के दस्तावेज हैं। एक सबसिस्टम के लिए सभी दस्तावेजों की सूची और एक सबसिस्टम के लिए दस्तावेजों के सभी स्थिर विशेषताओं (राज्यों, प्रकार, फ़ोल्डर्स) की एक सूची प्रदर्शित करने में सक्षम होना आवश्यक है।
एक Enum मॉड्यूल बनाएं जो सबसिस्टम को चिह्नित करता है
CREATE TYPE ref.module AS ENUM ( 'bdg', 'crm', 'ecm', 'wms', 'scm', ... );
और इन तालिकाओं में प्रकार मॉड्यूल का एक क्षेत्र जोड़ें। नतीजतन, हमारे पास सभी एप्लिकेशन दस्तावेजों के लिए एक सामान्य पीके, सीआरयूडी प्रसंस्करण के लिए एक सामान्य कोड, किसी भी दस्तावेज से अन्य उप-प्रणालियों के दस्तावेज़ से लिंक करने की क्षमता, एक दस्तावेज़ के साथ कार्य करने के अधिकारों का एक सामान्य सिस्टम, आदि।
नतीजतन, तालिकाओं की संख्या और डेटाबेस के साथ काम करने वाले कोड का आकार परिमाण के एक क्रम से कम हो जाएगा। हमारे लिए जो कुछ भी है वह इस दृष्टिकोण को दूसरों तक पहुंचाने के लिए है।
आवेदन की बुनियादी संस्थाओं:
स्थिरांक (प्रकार और दस्तावेजों की स्थिति, समकक्षों की विशेषताएं, दस्तावेज़ संबंधों के प्रकार, पहुंच मोड, भेजने के प्रकार) और
संपादन योग्य निर्देशिका (टैग, भूमिका, ..)।
हम दो टेबल कांस्ट और रेफरी बनाते हैं और दो इन टेबल के रिकॉर्ड प्रकारों की विशेषता के लिए दो एनुम बनाते हैं। और दस्तावेजों और संपादन योग्य निर्देशिकाओं के पेड़ की संरचना को बनाए रखने के लिए doc.folder और ref.folder आवेदन की दो और सामान्य तालिकाएँ।
इस तरह के एकीकरण की कमियों में से एक आधार स्तर पर फ़ील्ड का सख्त प्रतिबंध है (अर्थात, "दस्तावेज़ टैग के लिए लिंक" फ़ील्ड में संपादन योग्य निर्देशिका के लिए FK होगा)।
यह माना जाता है कि संपादित "टैग" निर्देशिका का रिकॉर्ड प्रकार एप्लिकेशन स्तर पर नियंत्रित किया जाता है।
आपकी टिप्पणियों के लिए धन्यवाद, टिप्पणियों का स्वागत है।
संदर्भ: