क्या वर्तमान साक्ष्य कैनोनिकल डेटा मॉडल पर प्रासंगिक होने को अपनाने का समर्थन करते हैं?


9

"विहित" विचार सॉफ्टवेयर में व्याप्त है; Canonical Model , Canonical Schema , Canonical Data Model इत्यादि जैसे पैटर्न विकास में बार-बार आते हैं।

कई डेवलपर्स की तरह, मैंने अक्सर, अनजाने में, पारंपरिक ज्ञान का पालन किया है, जिसे आपको एक कैनोनिकल मॉडल की आवश्यकता होती है, अन्यथा आपको मैपर और अनुवादकों के दहनशील विस्फोट का सामना करना पड़ेगा । या कम से कम, मैं करने के लिए इस्तेमाल करते हैं कि पहले कुछ साल तक जब मैं पहली बार कुछ हद तक कुख्यात पढ़ा एफई कोई विश्वास मत :

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

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

इसलिए मैं सोच रहा हूं, क्या किसी सॉफ्टवेयर सिस्टम या आर्किटेक्चर में विवादास्पद मॉडल बनाम प्रासंगिक मॉडल होने के व्यावहारिक, दीर्घकालिक प्रभावों पर कोई गंभीर शोध किया गया है?

या, अगर यह पूछना जल्दबाजी होगी, तो क्या किसी भी डेवलपर्स / वास्तुकारों ने व्यक्तिगत अनुभवों के बारे में सीडीएम से स्वतंत्र संदर्भ मॉडल, या इसके विपरीत स्विच करने के बारे में लिखा है, और उत्पादकता, जटिलता या विश्वसनीयता जैसी चीजों पर व्यावहारिक प्रभाव क्या थे?

विभिन्न स्तरों पर अंतर के बारे में क्या है, अर्थात एक ही आवेदन भर में एक ही मॉडल का उपयोग करके बनाम इसे अनुप्रयोगों की एक प्रणाली या एक पूरे उद्यम का उपयोग करके?

(केवल तथ्य, कृपया; युद्ध की कहानियों का स्वागत है लेकिन कोई अटकल नहीं है।)


मुझे नहीं पता कि वे "वोट ऑफ नो कॉन्फिडेंस" लेख के बारे में क्या बात कर रहे हैं। लेख का बाकी हिस्सा समझ में आता है, लेकिन Canonicalism के बारे में अनुभाग इतना सार है कि इसका कोई मतलब नहीं है। यह अच्छा होता अगर वे इस बारे में एक उदाहरण प्रदान करते कि वे किस बारे में बात कर रहे थे।
रॉबर्ट हार्वे

@ रॉबर्ट: मुझे कोई अंदाजा नहीं है अगर इसमें कोई सच्चाई है लेकिन यह मेरे लिए बहुत स्पष्ट है कि इसका क्या मतलब है ... निश्चित रूप से आप सीएम / सीडीएम पैटर्न से परिचित हैं? अपने सबसे सरल अवतार में, यह एक एकल अखंड ईएफ (या एसक्यूएल के लिए लाइनक, या जो कुछ भी) मॉडल / संदर्भ साझा कर रहा है, आवेदन के विशिष्ट भागों के लिए विशिष्ट प्रश्नों को लिखने के अधिक (कथित) डक्ट-टेपी दृष्टिकोण के बजाय पूरे आवेदन में। उच्च स्तर पर, यह संपूर्ण संगठन के लिए एक सार्वभौमिक स्कीमा को अपना रहा है जिसे सभी व्यक्तिगत अनुप्रयोगों / प्रणालियों को अनुवाद करना होगा।
एरोनॉट को

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

@ रॉबर्ट, यह मेरा उद्देश्य "ईएफ बहस" को लाने का नहीं था, मैंने सिर्फ एक ही उद्धरण उस पृष्ठ से लिया क्योंकि यह वह जगह थी जहां मैंने पहली बार तर्क सुना था (और मुझे यकीन नहीं है कि मैंने इसे सुना है। स्पष्ट रूप से कहीं और व्यक्त)। अलग-अलग, मुझे यकीन नहीं है कि मैं सहमत हूं कि तालिका-पहला डिज़ाइन वास्तव में एक अखंड मॉडल का प्रतिनिधित्व करता है; डेटाबेस ही है, लेकिन केवल DBMS वास्तव में इसके बारे में पता है - आवेदन के विभिन्न भागों केवल उन विशिष्ट तालिकाओं और प्रश्नों से अवगत होते हैं, जिन पर वे निर्भर करते हैं।
आरोनॉट

जवाबों:


5

नो कॉन्फिडेंस लेख के EF वोट के जवाब में , टिम मल्लियेलु लिखते हैं:

हम अनुशंसा नहीं कर रहे हैं कि लोग उन दिनों में लौट आएं जहां हम "कैनोनिकल स्कीमास" के लिए एक्सएसडी के उपयोग को प्रचारित कर रहे थे। मुझे विश्वास नहीं होता कि लोग सोचते हैं कि यह ट्रैक्टेबल है। हालाँकि हम जो मानते हैं, वह यह है कि एक ही मेटा-मॉडल (यदि आप चाहें तो EDM) के लिए वांछनीय है, जिसके साथ आप कई डोमेन मॉडल का वर्णन कर सकते हैं और यह कि एक एकल व्याकरण होने से हम किसी भी सामान्य सेवाओं का एक सेट प्रदान कर सकते हैं डोमेन मॉडल दिया गया।

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

कैन्यनियल मॉडल के लिए विकिपीडिया लेख एंटरप्राइज सर्विस बस , सर्विस-ओरिएंटेड आर्किटेक्चर और CORBA जैसी चीजों का संदर्भ देता है , जो कि ऐसा लगता है कि वे अब तक शायद ही बात करते हैं। उन्हें उद्यम के डेटा प्रसार और संचार चुनौतियों के समाधान के रूप में प्रस्तुत किया गया था, वन रिंग टू रूल थेम ऑल। टीएम क्या वे सफल हुए? या वे अपने स्वयं के वजन के तहत गिर गए?


आपने व्यक्तिगत अनुभव मांगे हैं, इसलिए मैं आपको एक जानकारी दूंगा। एयरोस्पेस उद्योग में हम टेलीमेट्री का बहुत उपयोग करते हैं। टेलीमेट्री सिस्टम के साथ चुनौतियों में से एक अलग-अलग टेस्ट रेंज के लिए एक सार्थक तरीके से एक-दूसरे के साथ परीक्षण डेटा संवाद करने का एक तरीका है। जब तक आप सामान्य शब्दों के डेटा शब्दकोश को परिभाषित करने का प्रयास नहीं करते हैं, यह समस्या काफी सरल लगती है।

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

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


बड़ी कंपनियों का सामना करने वाली समस्याएं समान हैं। Microsoft अखंड शब्दों में सोचने की कोशिश करता है, लेकिन ऐसा इसलिए है क्योंकि उनकी कंपनी बड़ी और अखंड है। जैसे ही आपको विभिन्न कंपनियों के बीच विभिन्न संस्कृतियों और व्यापार करने के तरीकों (या यहां तक ​​कि एक ही कंपनी में असमान विभागों के बीच) के बीच संवाद करने की आवश्यकता होती है, वन रिंग टू रूल देम ऑल। टीएम तुरंत टूटना शुरू कर देता है।


यह जानना दिलचस्प है कि Microsoft डिज़ाइनर स्वयं साझा मेगा-मॉडल की अनुशंसा नहीं करते हैं; दुर्भाग्य से यह ठीक है कि Linq को SQL और EF और कई अन्य ORM का उपयोग कैसे किया जाता है। भले ही, वहाँ अभी भी बहुत से लोग वहाँ हैं Canonical मॉडल अवधारणा को बढ़ावा देने और मैं अभी भी जानना चाहता हूँ कि यह कैसे व्यवहार बनाम किराए में वैकल्पिक है।
आरोनोटेड

@ चेतावनी: मेरा संपादन देखें
रॉबर्ट हार्वे

यह एक अच्छा संपादन है, और FYI करें मैंने इसे बढ़ा दिया है। हालाँकि, मैं पहले से ही कई विशिष्ट असंगति के मुद्दों के बारे में जानता हूँ जो एक मॉडल को स्पष्ट करने की कोशिश कर रहे हैं; मैं उन टीमों के बारे में अनुभवों या दीर्घकालिक डेटा के बारे में जानने में विशेष रूप से दिलचस्पी रखता हूं, जिन्होंने उन असंगतियों को हल करने के लिए समय का निवेश किया है, ताकि प्रति समापन बिंदु (अंत-से-मॉडल) के लिए एक मैपर हो, या अलग-अलग समय में निवेश करना। -एंड-एंड मैपर के बजाय, और जो वास्तव में सबसे कम लागत / सबसे कम जटिलता समाधान प्राप्त करता है।
Aaronaught

या इसे अधिक संक्षेप में कहें: मुझे पता है कि एक विहित मॉडल को बनाने और बनाए रखने के लिए बहुत काम है, जो मैं जानना चाहता हूं वह है जब (यदि कभी) लाभ लागत को पल्ला झुकना देखा गया है।
Aaronaught
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.