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