डेटाबेस की कमी का क्या हुआ?


46

जब मैं आरडीबीएमएस के लिए डेटाबेस मॉडल की समीक्षा करता हूं, तो मुझे आमतौर पर कोई अड़चन नहीं मिलती है (एक तरफ पीके / एफके)। उदाहरण के लिए, प्रतिशत अक्सर प्रकार के कॉलम में संग्रहीत किया जाता है int(जबकि tinyintअधिक उपयुक्त होगा) और CHECKमान को 0..100 सीमा तक सीमित करने के लिए कोई बाधा नहीं है । SE.SE पर इसी तरह, जांच की कमी का सुझाव दे जवाब अक्सर प्राप्त टिप्पणियों सुझाव है कि डेटाबेस की कमी के लिए गलत जगह है।

जब मैं बाधाओं को लागू नहीं करने के निर्णय के बारे में पूछता हूं, तो टीम के सदस्य जवाब देते हैं:

  • या तो वे यह भी नहीं जानते कि उनके पसंदीदा डेटाबेस में ऐसी विशेषताएं मौजूद हैं। यह केवल ओआरएम का उपयोग करने वाले प्रोग्रामर से समझा जा सकता है, लेकिन डीबीए से बहुत कम है जो किसी दिए गए आरडीबीएमएस के साथ 5+ वर्ष का अनुभव होने का दावा करते हैं।

  • या कि वे आवेदन स्तर पर ऐसी बाधाओं को लागू करते हैं, और डेटाबेस में उन नियमों की नकल करना एक अच्छा विचार नहीं है, SSOT का उल्लंघन है।

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

टीम से FKs का उपयोग न करने के विकल्प के बारे में पूछने पर, वे बताते हैं कि:

  • यह PITA है, उदाहरण के लिए जब किसी को एक तत्व को निकालना होता है जिसे अन्य तालिकाओं में संदर्भित किया जाता है।

  • NoSQL चट्टानों, और वहाँ कोई विदेशी चाबियाँ नहीं हैं। इसलिए, हमें RDBMS में उनकी आवश्यकता नहीं है।

  • यह प्रदर्शन के मामले में एक बड़ी बात नहीं है (संदर्भ आमतौर पर छोटे डेटा सेट पर काम करने वाले छोटे इंट्रानेट वेब अनुप्रयोग हैं, इसलिए वास्तव में, यहां तक ​​कि अनुक्रमित भी बहुत अधिक नहीं होगा; कोई भी परवाह नहीं करेगा यदि दिए गए क्वेरी का प्रदर्शन 1.5 एस से गुजरता है; । 20 से.मी.)

जब मैं स्वयं आवेदन देखता हूं, तो मैं व्यवस्थित रूप से दो पैटर्न देखता हूं:

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

  • अनुप्रयोग मानता है कि डेटाबेस से आने वाला सभी डेटा पूरी तरह से मान्य है। यही है, अगर 102प्रतिशत के रूप में आता है, तो या तो कुछ, कहीं दुर्घटनाग्रस्त हो जाएगा, या इसे केवल उसी तरह प्रदर्शित किया जाएगा जैसा कि उपयोगकर्ता को होता है, जिससे अजीब स्थिति पैदा होती है।

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

और यहाँ मेरा सवाल आता है:

चेक की कमी के बिना रिलेशनल डेटाबेस को मॉडल करने और अंततः विदेशी कुंजियों के बिना भी क्या कारण हैं?


इसके लायक क्या है, यह सवाल और मुझे मिले जवाब (विशेष रूप से थॉमस किलियन के साथ दिलचस्प चर्चा) ने मुझे डेटाबेस की कमी के विषय पर अपने निष्कर्ष के साथ एक लेख लिखने के लिए प्रेरित किया ।


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

1
@JacquesB: आप एक उत्तर पोस्ट कर सकते हैं, क्योंकि "मैंने इसे दशकों से देखा है" एक बहुत ही अलग दृष्टि देता है कि मुझे एक घटना जो तीन-चार साल पहले दिखाई दी थी (यह देखते हुए कि मैंने आईटी में एक से भी कम समय के लिए काम किया है) दशक, घटना के बारे में मेरा दृष्टिकोण शायद गलत है)। इस प्रकार, निष्कर्ष भी बहुत अलग होगा।
बजे आर्सेनी मूरज़ेंको

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

1
इस प्रश्न को फिर से खोलने के लिए मतदान करना क्योंकि यह गलत तरीके से "मुख्य रूप से राय-आधारित" के रूप में बंद कर दिया गया है, जब तक कि उत्तर अब तक बताते हैं कि मामला नहीं है।
डेविड अरनो

3
मैं तुम्हारे साथ हूँ 110%।
पेरीटा ब्रीटाटा

जवाबों:


28

डेटाबेस के लिए विभिन्न उपयोग के मामलों के बीच अंतर करना महत्वपूर्ण है।

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

लेकिन ऐसी प्रणालियां भी हैं जहां डेटाबेस को एकल अनुप्रयोग के साथ कसकर एकीकृत किया जाता है। एकल एम्बेडेड डेटाबेस के साथ स्टैंड-अलोन एप्लिकेशन या वेब एप्लिकेशन। जब तक डेटाबेस विशेष रूप से एकल एप्लिकेशन द्वारा एक्सेस किया जाता है, तब तक आप अड़चन पर विचार कर सकते हैं - जब तक कि एप्लिकेशन सही ढंग से काम करता है। इन प्रणालियों को अक्सर प्रोग्रामर्स द्वारा एप्लिकेशन कोड पर ध्यान केंद्रित करके विकसित किया जाता है और शायद संबंधपरक मॉडल की गहरी समझ नहीं है। यदि अनुप्रयोग ORM का उपयोग करता है तो बाधाएँ ORM स्तर पर अनुप्रयोग प्रोग्रामर से अधिक परिचित रूप में घोषित की जा सकती हैं। कम अंत में हमारे पास MySQL का उपयोग करने वाले PHP अनुप्रयोग हैं, और लंबे समय तक MySQL ने मूल बाधाओं का समर्थन नहीं किया, इसलिए आपको स्थिरता सुनिश्चित करने के लिए एप्लिकेशन परत पर निर्भर रहना पड़ा

जब इन विभिन्न पृष्ठभूमि के डेवलपर्स मिलते हैं तो आपको एक संस्कृति टकराव मिलता है।

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


5
+! 1 कमरे में हाथी का उल्लेख करने के लिए: झूठी धारणा है कि एक आवेदन सिर्फ एक DB का उपयोग करता है और एक DB सिर्फ एक ऐप द्वारा उपयोग किया जाता है
Tulains Córdova

4
@ TulainsCórdova, मुझे लगा कि यहाँ के कमरे में हाथी Google की पेरोल प्रणाली है। :)
मचाडो

5
@ माचादो यह प्रतिभा है: "मैं शर्त लगाता हूं कि वे अपने पेरोल सिस्टम को कई बाधाओं के साथ एक संबंधपरक डेटाबेस पर
ट्यूलेंस कोरडोवा

2
यह ठीक से विवश डेटाबेस के लिए भी आसान है क्योंकि आपका एप्लिकेशन कोड ACID नहीं है।
मैथ्यू व्हाइट

3
केवल @ मैथ्यूव्हाइट द्वारा की गई टिप्पणी पर जोर देने के लिए, अनुप्रयोगों के लिए कुछ प्रकार के अंतर-पंक्ति / इंटर-टेबल बाधाओं को लागू करना संभव नहीं है, बिना लॉकिंग और अतिरिक्त क्वेरी चलाने के लिए। एक RDBMS बहुत कम लागत पर ऐसा कर सकता है।
डेविड एल्ड्रिज

15

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

कहा जा रहा है कि, जितने भी एप्लिकेशन स्केल किए जाने हैं, वे CAP प्रमेय द्वारा बाध्य हैं , जहां आपको 3 में से 2 को चुनना होगा: संगति, उपलब्धता और विभाजन सहिष्णुता (नेटवर्क फॉल्ट टॉलरेंस)।

CAP प्रमेय का अध्ययन करके आप देखेंगे कि बहुत अधिक विकल्प नहीं है, लेकिन उपलब्धता या संगति को खोने के लिए चुना गया है, क्योंकि आप नेटवर्क के 100% समय में वास्तव में भरोसा कर सकते हैं।

सामान्य तौर पर, कई एप्लिकेशन कुछ उचित समय के लिए असंगत हो सकते हैं, लेकिन उपयोगकर्ताओं के लिए अनुपलब्ध नहीं हो सकते। उदाहरण के लिए, फेसबुक या ट्विटर में थोड़ा असंयमित समयरेखा समय पर पहुंच नहीं होने से बेहतर है।

इस प्रकार, कई एप्लिकेशन रिलेशनल डेटाबेस की कमी को दूर करने के लिए चुन रहे हैं, क्योंकि रिलेशनल डेटाबेस वास्तव में कंसिस्टेंसी में अच्छे हैं, लेकिन उपलब्धता की कीमत पर।

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

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

- संपादित करें: -

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

हालांकि यह वैध है, यह मेरे लिए एक ग्रे क्षेत्र भी है, क्योंकि मैं आज कोई भी डेटाबेस इंजन नहीं ढूंढ सकता जो मूल प्रश्न में प्रस्तावित एक की तरह सरल बाधाओं का समर्थन नहीं करता है।


"मुझे आज कोई भी डेटाबेस इंजन नहीं मिल रहा है जो मूल प्रश्न में प्रस्तावित एक की तरह सरल बाधाओं का समर्थन नहीं करता है।" क्या MySQL अभी तक CHECK बाधाओं का समर्थन करता है?
विंसेंट सवार्ड

@VincentSavard, शायद सटीक CHECK MS SQL नहीं करता है, लेकिन यह किसी प्रकार का प्रतिबंध करता है: dev.mysql.com/doc/refman/5.7/en/constraint-invalid-dn.html
Machado

@ माचाडो - यह विशिष्ट बाधाओं के बारे में नहीं है, हालांकि, जब प्रश्नों को उचित प्रकारों में प्रतिनिधित्व नहीं किया जा सकता है, तो डेटा को शामिल करने की पहचान करना। जो वर्षों पहले स्थिति पर एक अलग सुधार है जब MySQL ने चुपचाप ऐसे मूल्यों को अनदेखा कर दिया था।
1924 में पेरीटा ब्रीटाटा

1
@PeriataBreatta, एक साइड नोट पर, मैं कभी भी पूरी तरह से समझ नहीं पाया कि MySQL "डे वास्तव" OSS डेटाबेस था जिसे वेबसाइट डेवलपर्स द्वारा चुना गया था, जब PostgreSQL पूरी तरह से उपलब्ध था और अधिक उन्नत था। शायद इसे स्थापित करना आसान था, मुझे नहीं पता।
मचाडो

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

10

चेक की कमी के बिना रिलेशनल डेटाबेस को मॉडल करने और अंततः विदेशी कुंजियों के बिना भी क्या कारण हैं?

पहले स्पष्ट कर दूं कि मैं यहां केवल आरडीबीएम के बारे में बात कर रहा हूं, बिना एसक्यूएल डेटाबेस के बारे में नहीं।

मैंने कुछ डेटाबेस को बिना FK या PK के देखा है, अकेले बाधाओं की जाँच करें लेकिन ईमानदारी से कहें कि वे अल्पसंख्यक हैं। शायद इसलिए कि मैं एक बड़ी कंपनी में काम करता हूं।

वर्षों के माध्यम से अपने अनुभव में मैं कह सकता हूं कि कुछ कारण हो सकते हैं:

  • शुरुआती या शौकीन प्रोग्रामर के मामले में , मॉडलिंग कौशल का अल
  • डेटाबेस दुनिया के साथ कोई वास्तविक संपर्क नहीं होने के साथ ओआरएम का व्यापक या लगभग अनन्य उपयोग
  • एक टीम या छोटे प्रोजेक्ट पर एक डीबीए या अन्य डेटा मॉडलिंग विशेषज्ञ की अनुपस्थिति
  • विकास के पहले चरणों में डीबीए या डेटा मॉडलिंग विशेषज्ञ की भागीदारी का अभाव
  • जानबूझकर डिजाइन फैसले डेवलपर समुदाय है कि कि यहां तक कि एक चेक बाधा है कि लागू करता है कि एक निश्चित स्तंभ केवल हो सकता है पर विचार करता है का एक हिस्सा द्वारा 1,2 or 3एक मूल्य के रूप में, या कि "उम्र" स्तंभ होना चाहिए >= 0है "डेटाबेस में व्यापार तर्क होने" । यहां तक ​​कि डिफ़ॉल्ट क्लॉज़ को कुछ लोग व्यावसायिक तर्क के रूप में मानते हैं जो डेटाबेस से संबंधित नहीं है, जैसा कि आप इस हालिया साइट में कई हालिया प्रश्नों और उत्तरों में देख सकते हैं। ऐसा डेवलपर्स जो ऐसा मानते हैं, स्पष्ट रूप से संभव के रूप में कुछ बाधाओं का उपयोग करेंगे और कोड में भी सब कुछ करेंगे, यहां तक ​​कि रेफेंसियल अखंडता और / या एकता भी। मुझे लगता है कि यह एक चरम स्थिति है।
  • आरडीबीएम का उपयोग कुंजी-मूल्य भंडार के रूप में , या तो नो-एसक्यूएल व्यवहार का अनुकरण करने के लिए क्योंकि आवश्यक जहां आरडीबीएमएस टेबल का उपयोग करके संतुष्ट होने के लिए आवश्यक सरलताएं कुंजी-मूल्य रिपॉजिटरी को अलग करती हैं।
  • यह मानते हुए कि डेटाबेस को हमेशा "एप्लिकेशन" द्वारा लिखा जाएगा और किसी को भी कभी भी बड़े पैमाने पर डेटा लोड करने, या SQL क्लाइंट के माध्यम से पंक्तियों को संपादित या सम्मिलित करने की आवश्यकता नहीं होगी (कई मामलों में ऐप को खराब डेटा को सही करने के लिए डाला जाता है)। सर्वोत्तम स्थिति में एस्सेनारियो में हमेशा एक अन्य ऐप ("ऐप" के अलावा) डेटाबेस को डीएमएल निर्देश जारी करेगा: एक एसक्यूएल क्लाइंट।
  • यह एहसास नहीं है कि डेटा व्यवसाय के स्वामी का है , ऐप का नहीं।

उन्होंने कहा कि, मैं बताना चाहूंगा कि RDBMS सॉफ्टवेयर के बहुत ही उन्नत टुकड़े हैं जो दिग्गजों के कंधों पर बनाए गए हैं और कई व्यावसायिक आवश्यकताओं के लिए बहुत कुशल साबित हुए हैं, जो एक श्रृंखला पर संदर्भात्मक अखंडता के कुशल कार्य के सांसदों को मुक्त करते हैं। द्विआधारी फ़ाइलों या पाठ फ़ाइलों की। जैसा कि मैं हमेशा कहता हूं "हम अब एक-ऐप-वन-डेटाबेस दुनिया में नहीं रहते हैं" । बहुत कम से कम एक SQL क्लाइंट "एप्लिकेशन" के अलावा DML जारी करेगा। इसलिए डेटाबेस को मानवीय या प्रोग्रामिंग त्रुटियों से उचित हद तक बचाव करना चाहिए

RDBMS अच्छी तरह से पैमाने पर नहीं होगा, जहां उन सभी प्रकार की आवश्यकताओं में, हर तरह से नो-एसक्यूएल तकनीक को गले लगाते हैं । लेकिन यह बिना किसी अड़चन के साथ संबंधपरक डेटाबेस के प्रसार की चिंता कर रहा है जहां कोड की हजारों लाइनें (उत्पन्न या टाइप) को लागू करने के लिए समर्पित है कि आरडीबीएमएस को आपके लिए और अधिक कुशल तरीके से लागू करना चाहिए।


3

बाहरी बाधाएं हैं जो प्रौद्योगिकी निर्णय लेती हैं। ऐसी कुछ ही स्थितियाँ हैं जहाँ आपको नियमित आधार पर डेटाबेस फ़ील्ड की कमी का उपयोग करने की आवश्यकता और विलासिता है।

  1. उद्यमों में डीबीए के साथ-साथ ऐप और डेटाबेस दोनों के लिए डेवलपर्स हैं, लेकिन अधिकांश डेवलपर्स इस प्रकार के वातावरण में काम नहीं करते हैं। वे कोड में जितना कर सकते हैं उतना करते हैं। इसके अलावा, डेटाबेस के कुछ पक्ष व्यावसायिक नियमों में शामिल नहीं होते हैं। वे मुख्य रूप से चीजों को चालू रखने के लिए हैं। वे DB में बाधाओं के लिए कभी धक्का नहीं देंगे। विरासत ऐप्स, एकीकरण, माइग्रेशन, विलय, अधिग्रहण से निपटने के लिए एक db बाधा सबसे अच्छा समाधान हो सकता है।
  2. डीबी को ओवरलोड करने से एक अड़चन पैदा हो सकती है जो समस्या पर अधिक मशीनों को फेंककर आसानी से हल नहीं होती है। ऐसी कुछ स्थितियाँ हैं जहाँ db भाषा प्रमुख प्रदर्शन हिट के बिना कुछ प्रोग्रामिंग समस्याओं को संभालती नहीं है, इसलिए आप हर चीज के लिए एक बाधा का उपयोग करने की योजना नहीं बना सकते हैं। Stackoverflow में एक डेटाबेस सर्वर है क्योंकि किसी समस्या पर 2 को फेंकना एक चुनौती है।
  3. स्वचालित परीक्षण - वे वहां हो रहे हैं, लेकिन कई डीबी डेवलपर्स आईडीई / परीक्षण ढांचे के साथ पार्टी के लिए देर से हैं।
  4. तैनाती - अधिक db सामान इसे और अधिक जटिल बनाता है। जब क्लाइंट के डेटाबेस को अपडेट करने की अनुमति नहीं होती है तो क्या होता है क्योंकि डेटा का उल्लंघन होता है? जब तक आपके पास यह पता करने का कोई तरीका नहीं है तब तक गेम खत्म करें। अपने ऐप में, आप उपयोगकर्ता को आवश्यकतानुसार इसे संभालने देने का निर्णय ले सकते हैं या कुछ व्यवस्थापकों को इसे बैच में करने का निर्देश दे सकते हैं।
  5. केवल ऐप / एपीआई / सेवा कभी भी डेटाबेस को डेटा लिखेंगे तो परेशान क्यों होंगे? यह ज्यादातर समय ऐसा ही होता है, यही कारण है कि यह आम नहीं है।
  6. अगर सब कुछ अजीब से बाहर हो जाता है तो संघर्ष करने के लिए सैकड़ों अवरोध उल्लंघन के बिना db त्रुटियों को संभालना काफी कठिन होता है। अधिकांश लोग संबंध बनाने से खुश होते हैं और तालिका का नाम सही पाते हैं।

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


2

यह एक ऐसी समस्या है जिसे मैंने अपने सभी करियर (लगभग 40 साल) के साथ संघर्ष किया है और यह भी कि जब मेरा डीबीएमएस लिख रहा है। मेरे अंतिम बिंदु का विवरण यहां है: http://unibase.zenucom.com । तो यहाँ मेरे विचार हैं।

  1. आमतौर पर बोलने वाले अधिकांश अवरोधों को बेहतर तरीके से अनुप्रयोग में संभाला जाता है ताकि आवेदन के विभिन्न हिस्से अलग-अलग बाधाओं को लागू कर सकें। उदाहरण के लिए, एक राज्य कोड सभी न्यायालयों में लागू नहीं हो सकता है।
  2. एक% से सावधान रहें। मार्कअप हैं> 100% या आप टूट गए :)
  3. बाधाओं को सबसे अच्छा नकारात्मक रूप से वर्णित किया गया है। यानी वे जो नहीं हो सकते, वे नहीं जो वे होने चाहिए। यह हमेशा एक सरल सूची है।
  4. विदेशी कुंजी हमेशा अच्छी होती है और इसका उपयोग किया जाना चाहिए। पूर्ण विराम। FK RDBMS में कुछ अर्थ निर्माणों में से एक है और बहुत उपयोगी है। सबसे बड़ी कठिनाई यह तय करना है कि क्या एफके को हटा दिया जाए या एफके रिकॉर्ड को न हटाने के कारण निर्भर पंक्तियों का उपयोग करें।
  5. वास्तविक दुनिया में बाधाएं आमतौर पर एकल क्षेत्र मूल्य प्रतिबंध की तुलना में अधिक जटिल होती हैं।
  6. कुछ बाधाओं, यहां तक ​​कि आवेदन के स्तर पर भी, अच्छे संचालन के खिलाफ काम करते हैं। उदाहरण के लिए आक्रामक तारीखों की जाँच स्पष्ट रूप से अच्छी तारीखों में त्रुटियों को छिपाती है। अन्यथा समझदार दिखने वाली तिथियों में त्रुटियों का माप प्राप्त करने के लिए आपको ऑपरेटर की त्रुटि की आवश्यकता होती है।

1

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


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

5
मेरी समझ यह है कि यदि प्रतिशत बाधा का उल्लंघन किया जाता है, तो आपको इस अपवाद को संभालने की आवश्यकता नहीं है , क्योंकि इस तरह के उल्लंघन से संकेत मिलता है कि पहली बार में आपके कोड में एक बग है (या तो किसी ने Percentageकक्षा के एक उदाहरण के बजाय एक साधारण पूर्णांक का उपयोग किया है ,) या स्वयं सत्यापन में कोई त्रुटि है), एक असाधारण मामले के विपरीत (जैसे कि एक नेटवर्क कनेक्शन नीचे है)। मेरे लिए, उल्लंघन को वेब ऐप के लिए HTTP 500 या डेस्कटॉप ऐप के लिए क्रैश होना चाहिए, और फिर इसे लॉग और फिक्स्ड किया जाना चाहिए।
आर्सेनी मूरज़ेंको

7
@ThomasKilian: नहींं; ठीक इसके विपरीत। गलत डेटा नहीं मिलेगा, विशेष रूप से क्योंकि डेटाबेस की कमी है। यदि आपका व्यावसायिक तर्क कोड में सही है, तो आप उन बाधाओं का उल्लंघन पहले कभी नहीं करेंगे। यदि कोई कोड में बग होता है, तो वे बाधाएँ इस बग के बारे में आपको सचेत कर देंगी, जबकि डेटाबेस को स्क्रैप से सुरक्षित रखा जाएगा।
आर्सेनी मूरज़ेंको

9
@ThomasKilian: मुझे नहीं लगता है कि कोई भी "पहले स्थान पर इसे सही बनाने" के खिलाफ बहस कर रहा है - यह शायद अधिक है कि कोई भी अनुभव के साथ कोई भी जानता है कि इस धारणा पर एक प्रणाली डिजाइन करना एक बुरा विचार है जो आप करेंगे पहली बार सबकुछ ठीक हो जाए और सिस्टम के जीवनकाल के दौरान कोई बग या गलती कभी नहीं होगी । DB अवरोध यह सुनिश्चित करते हैं कि बग या गलती डेटाबेस को दूषित नहीं करती है।
जैक्सबी

3
@JacquesB मैं पवन चक्कियों के खिलाफ लड़ रहा हूं। यदि आप DB में व्यावसायिक तर्क रखते हैं तो यह पहले स्थान पर विफल हो सकता है और आपको उसी तरह नहीं बचा सकता है। लेकिन (!) अब आपके पास व्यावसायिक तर्क है जहां यह नहीं है। यह मानना ​​कि DB आपके सड़े हुए व्यापार तर्क को बचा सकता है, बस गलत है। DB में तर्क को पूरे व्यापार तर्क के समान नियमों का पालन करना पड़ता है।
qwerty_so

1

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

उम्मीद है कि सॉफ्टवेयर "चीजों को बाहर काम करेगा" अक्सर अवास्तविक होते हैं, और यह उन बाधाओं को पैदा नहीं करता है जो एक मानव करेगा।

सर्वोत्तम परिणामों के लिए, SQL का उपयोग करके तालिकाओं का निर्माण करें और मैन्युअल रूप से बाधाओं को जोड़ें, लेकिन कभी-कभी लोग ऐसा नहीं कर सकते।


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