SQL सर्वर के भीतर NoSQL

Question

यह प्रश्न SQL और NoSQL के बीच अंतर के बारे में नहीं है। मैं किसी ऐसी चीज़ के लिए कुछ औचित्य की तलाश कर रहा हूं जो वास्तव में मेरे लिए इस समय समझ में नहीं आता है (शायद मेरी समझ या प्रशंसा की कमी के कारण)।

हमने MVC5, एंटिटी फ्रेमवर्क 6 कोड फर्स्ट और SQL सर्वर 2008 का उपयोग करते हुए स्क्रैच से एक नई परियोजना शुरू की है। जब आर्किटेक्ट ने डेटाबेस स्कीमा की समीक्षा की तो यह कहा गया कि सभी विदेशी कुंजी और अन्य बाधाओं को हटा दिया जाना चाहिए क्योंकि यह "व्यावसायिक तर्क" है। आवेदन कोड की व्यावसायिक परत के भीतर लागू किया जाना चाहिए।

मेरी राय है कि विदेशी कुंजियाँ डेटा / संदर्भात्मक अखंडता का हिस्सा बनती हैं और वास्तव में व्यावसायिक तर्क की नकल नहीं करती हैं। मैं व्यावसायिक तर्क को अधिक प्रक्रिया और मान्यता के रूप में देखता हूं जो संदर्भों को लागू करने के लिए क्या / कब / कैसे / क्यों नियंत्रित करता है। मैं यह समझ सकता हूं कि अद्वितीय बाधाएं निश्चित रूप से व्यावसायिक प्रक्रियाएं हैं, लेकिन मेरे लिए यह सिर्फ तर्क का अनुपालन करती है और अखंडता का हिस्सा बनती है।

एक दूसरा तर्क यह है कि डेटा के लिए NoSQL दृष्टिकोण को अपनाना है। मुझे यह वास्तव में असामान्य और अपरंपरागत लगा: एसक्यूएल-सर्वर 2008 के उपयोग, रिपोर्टिंग की आवश्यकता, टेराबाइट्स को स्केलिंग नहीं करने का डेटा और मोंगो, रेवेन आदि जैसी तकनीकों के प्रति विचार की कमी।

क्या इससे पहले कोई इस तरह के परिदृश्य पर आया है? रेफ़रल डेटा के लिए डिज़ाइन किए गए SQL सर्वर में कोई NoSQL दृष्टिकोण क्यों अपनाएगा और विदेशी कुंजियाँ नहीं चाहेगा?

Comments

उसकी सलाह के औचित्य के बारे में अपने सिस्टम आर्किटेक्ट से बात करें। या तो उसके पास एक बहुत अच्छा कारण है जो आपके विशिष्ट मामले पर लागू होता है (एक ऐसा कारण जो हम आवश्यक रूप से अनुमान नहीं लगा पाएंगे, बिना यह जाने कि आपका ऐप क्या है), या वह सिर्फ अक्षम है।

— आर्सेनी मौरज़ेंको

मैंने कई डेटाबेस को एक समान तरीके से लागू किया है: कोई FKs, कोई CHECK की कमी नहीं - हर बार अनुभवहीन कोडर्स द्वारा डिज़ाइन किए गए डेटाबेस जो डेटाबेस आर्किटेक्चर, संदर्भात्मक अखंडता, आदि के बारे में कुछ नहीं जानते थे, लेकिन आपके साथ इस पर चर्चा करना महत्वपूर्ण है। आपके सहकर्मी, केवल यह मानने के बजाय कि वह अक्षम है।

— आर्सेनी मूरज़ेंको

मैं थोड़ा उलझन में हूँ; आप एंटिटी फ्रेमवर्क (पहले कोड) का उपयोग करते हुए उल्लेख करते हैं ... इसका मतलब यह नहीं है कि आप ऑब्जेक्ट (सी # अर्थ में) बनाते हैं और फिर एंटिटी फ्रेमवर्क को डेटाबेस समकक्ष बनाने में संभालते हैं, जिस स्थिति में एफके आदि को जोड़ने / निकालने की कोशिश कर रहा है। एंटिटी फ्रेमवर्क को आउट करने की कोशिश में एक अभ्यास (जो मार्क ट्वेन के उद्धरण की तरह एक गाना सिखाने की कोशिश के बारे में है?)

— फ़ून

बहुत सारे लोग हैं जो खुद को "आर्किटेक्ट" का दावा करते हैं, लेकिन वास्तव में बड़ी प्रणालियों को कोड करने या बनाए रखने का अनुभव नहीं है।

— डॉक्टर ब्राउन

प्रासंगिक: thedailywtf.com/articles/The-Mythical-Business-Layer । "यदि आप इसके बारे में सोचते हैं, तो सॉफ़्टवेयर एप्लिकेशन में कोड की लगभग हर पंक्ति व्यावसायिक तर्क है।" यह डेटाबेस तक फैली हुई है। "लेकिन यह उतना ही महत्वपूर्ण है - यदि अधिक नहीं - तो यह ध्यान रखें कि एप्लिकेशन के लगभग सभी कोड व्यावसायिक तर्क होंगे। वहां पहले से ही पर्याप्त उपकरण हैं; आपके आवेदन को एक जेनेरिक परत की आवश्यकता नहीं है " (जोर मेरा)। यह अनुशंसा करने वाला व्यक्ति संभवतः डेटाबेस को एक ऐसी सामान्य परत में बदलने की कोशिश कर रहा है। संक्षेप में, वे सबसे अधिक वास्तविकता के ऊपर buzzwords डाल रहे हैं।

— jpmc26

Answer 1

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

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

उसे समझाने की कोशिश करें कि संदर्भात्मक अखंडता बाधाएं "व्यावसायिक तर्क" नहीं हैं; वे अपने स्वयं के निर्मित सत्यापन के साथ एक शुद्धता मानक हैं। व्यावसायिक तर्क इस बारे में है कि आप डेटा के साथ क्या करते हैं; अखंडता यह सुनिश्चित करने के बारे में है कि डेटा स्वयं भ्रष्ट नहीं है। और अगर वह काम नहीं करता है ... ठीक है, वह प्रभारी है। आप या तो उसकी योजना के साथ जा सकते हैं और कुछ हद तक नुकसान को कम करने की कोशिश कर सकते हैं, या काम करने के लिए बेहतर जगह की तलाश कर सकते हैं। (अथवा दोनों।)

Comments

मेरे पास थोड़ा अधिक कूटनीतिक उत्तर था जिसने एक (समझदार) कारण खोजने की कोशिश की कि वास्तुकार ऐसा क्यों कर रहा है। शांत प्रतिबिंब पर, मैं इस जवाब के बजाय बोर्ड पर ले रहा हूं।

— ब्लरफ्ल

वाहा वाया, खराब आर्किटेक्चर के प्रयास कहीं और जाने का कारण हैं? धिक्कार है, मैं कभी भी काम करने में सक्षम नहीं होता अगर मैं उस दृष्टिकोण को लेता।

— Kzqai

@Kzqai आर्किटेक्चर को आर्किटेक्चर की गलतफहमी में भी गलत समझा जाता है। यह निर्देश 595 की तरह लग रहा है और हाँ, अगर कोई मुझे लकड़ी के एक टुकड़े में शिकंजा लगाने के लिए हथौड़ों का उपयोग करने के लिए मजबूर करना चाहता था, तो मुझे कोई ऐसा व्यक्ति मिलेगा जो मुझे कुछ बनाने के लिए उपकरणों का दुरुपयोग करने के लिए मजबूर नहीं कर रहा है।

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

@AndyClark आपको इस पर छोड़ देना चाहिए। कारण यह है कि यह आपकी कंपनी के मूल में एक परमाणु समय बम है। यह केवल एक समय की बात है जब फेकल मामला वेंटिलेटर पर थोपता है। जब ऐसा होता है, तो आप 72 घंटे की शिफ्ट में काम करने के लिए भाग्यशाली होंगे, सबसे खराब स्थिति यह है कि आप एक नौकरी की तलाश कर रहे हैं ... जब आपके पास आय होगी तो नौकरी की तलाश करना बेहतर होगा।

— ArTs

Answer 2

मेरे पास अभी तक एक विदेशी कुंजी बनाने का कारण नहीं है

- जोएल स्पोल्स्की

एक तरफ कंबल बयान, यह स्वीकार करने योग्य है कि विशिष्टता या विदेशी कुंजी बाधाओं का उपयोग नहीं करने के लिए वैध और मजबूत कारण हैं। सबसे कुछ इस तरह से जाना:

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

यह भी देखें कि विदेशी चाबियों में क्या गलत है?

---

लेकिन वे आपके प्रश्न के कारणों से मेल नहीं खाते हैं।

यह व्यावसायिक तर्क है और इसे व्यावसायिक स्तर पर लागू किया जाना चाहिए।

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

एक दूसरा तर्क यह है कि वे अपने डेटा भंडारण के लिए NoSQL दृष्टिकोण को अपनाना चाहते हैं और इसलिए इस तरह के प्रतिबंध नहीं चाहते हैं।

दूसरा कारण वास्तव में एक कारण नहीं है; यह एक निष्कर्ष है। हालांकि यह सच है कि अड़चनें प्रदर्शन और प्रदर्शन के बीच व्यापार-बंद हैं, और NoSQL डेटाबेस पूर्वाग्रह की ओर अग्रसर हैं।

---

शायद आपके सिस्टम आर्किटेक्ट के पास इन वैध कारणों को ध्यान में रखते हुए, और आप इसे गलत मानते हैं। या हो सकता है कि वह एक मूर्ख व्यक्ति हो।

किसी भी मामले में, विशिष्टता और विदेशी प्रमुख बाधाओं का उपयोग करने से बचने के लिए वैध (हालांकि सार्वभौमिक नहीं ) कारण हैं।

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

Comments

मैं कहता हूं कि जोएल एक बेवकूफ नहीं है, लेकिन पॉडकास्ट में एक मजाकिया जवाब, बिना किसी स्पष्टीकरण के, आईएमएचओ, इसके लायक भी कम है कि किसी भी बेवकूफ से एक बयान।

— मार्टिन बा

जोएल एक स्प्रेडशीट लड़का है, एक डेटाबेस लड़का नहीं है, इसलिए मानक संबंधपरक डेटाबेस प्रथाओं की उसकी अज्ञानता है, मुझे लगता है, आश्चर्य नहीं ... कोई अपराध नहीं, जोएल। :-)

— एरिक किंग

जोएल के संदर्भ में वास्तविक उद्धरण प्रौद्योगिकियों है, जैसे कि LINQ, एक विदेशी कुंजी को सेट करने के लिए परेशान करने का कारण प्रदान करता है। जोएल एक डेटाबेस प्रशासक नहीं है और अपने ब्लॉग को खोजने और एक लंबे समय से पाठक होने के नाते, मैं उससे विषय के बारे में बात करने या डेटाबेस को अनुकूलित करने, डेटा मॉडल तैयार करने आदि के बारे में सलाह देने की कोशिश कर रहा है, जोएल का कमाल नहीं है। , लेकिन वह अब नहीं है और न ही वह कभी रहा है - या होने का दावा किया गया है! - डेटाबेस या डेटा मॉडलिंग के क्षेत्र में एक विशेषज्ञ। यह आइंस्टीन के चक्रवृद्धि ब्याज के बारे में उद्धृत करने जैसा है - या, उस मामले के लिए, सैंडविच। (एक्सकेसीडी संदर्भ, आपका स्वागत है।) :)

— ब्रायन

जोएल स्पोलस्की को मजबूत, विवादास्पद राय रखने के लिए जाना जाता है। देखें FogBugz एक मालिकाना भाषा में लिखा गया है ; निर्भरता इंजेक्शन बहुत जटिल है (btw, यह बंद होने से पहले Stackoverflow पर सबसे विवादास्पद जवाब था) ; XML डेटाबेस धीमा कर रहे हैं ; आदि

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

@BlueRaja: उम्म ... XML डेटाबेस हैं धीमी गति से विशेष रूप से रिलेशनल डेटाबेस की तुलना में,। वह विवादास्पद कब है, या एक राय है?

— मेसन व्हीलर