डीबी नहीं

लेखक ब्रुअर्स, डीबीएमएस निर्माताओं के उतार-चढ़ाव के बारे में बात करता है, स्वयं और संक्षेप में कि कैसे ठीक से एप्लिकेशन डिजाइन किए जाएं। लेख का शिक्षाप्रद हिस्सा मुझे उपयोगी लगा।

1920 के दशक में संयुक्त राज्य अमेरिका में, मादक पेय पदार्थों का उत्पादन, बिक्री और आयात संवैधानिक संशोधन द्वारा निषिद्ध था। संशोधन 13 साल बाद रद्द कर दिया गया था। प्रतिबंध के दौरान, बीयर उद्योग की मृत्यु हो गई।

1933 में, जब प्रतिबंध हटा लिया गया था, तो कई अनाज दिग्गजों ने बीयर पीना शुरू कर दिया था। उन्होंने बाजार पर पूरी तरह से एकाधिकार कर लिया। और लगभग 50 वर्षों तक, हमने राज्यों में इस कार्बोनेटेड मूत्र को पिया और इसे "बीयर" कहा। इस स्वाद को सहन करने का एकमात्र तरीका यह था कि इसे बहुत ठंडा पीया जाए।

60 के दशक में एक किशोर के रूप में, मैंने कभी भी उनके आकर्षण को नहीं समझा। बीयर क्यों? यह एक पीला पीला, गंदा तरल है जो बीमार सूअर के मूत्र से प्राप्त होता है। और मुझे एक भी वजनदार प्लस नहीं मिला।

1984 में, मैं इंग्लैंड गया, और मेरी आंखों से अंधे गिर गए। मैं आखिरकार मिल गया। मैंने पहली बार बीयर की कोशिश की और यह अच्छी हो गई ।

तब से, संयुक्त राज्य अमेरिका में बीयर की स्थिति में काफी सुधार हुआ है। नई शराब बनाने वाली कंपनियां पूरे देश में मशरूम की तरह बढ़ रही हैं, और ज्यादातर मामलों में वे जो बीयर बनाते हैं वह वास्तव में बहुत अच्छा है। हमारे पास कड़वी (एक कड़वी हॉन्टेड बीयर) की तरह सुंदर कुछ भी नहीं है, लेकिन हम पकड़ रहे हैं।

80 के दशक में, कई बड़ी कंपनियों ने अपने डेटाबेस के साथ बाजार पर एकाधिकार कर लिया। उन्होंने प्रबंधकों और विपणक के बीच भय, अनिश्चितता और संदेह पैदा करके ऐसा किया। "रिलेशनल" शब्द "गुणवत्ता" का पर्याय बन गया है, और डेटा संग्रहीत करने का कोई अन्य तरीका मना हो गया है।

उन दिनों, मैं एक अग्रणी डेवलपर था। हमारे सिस्टम ने T1 संचार लाइनों की गुणवत्ता को मापा। हमारा डेटा मॉडल अपेक्षाकृत सरल था, और हमने डेटा को सरल फ़ाइलों में संग्रहीत किया। यह ठीक काम किया।

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

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

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

हाँ, बिल्कुल। वास्तव में। वास्तविक प्रोग्रामिंग अनुभव के बिना जेलेज़ीचनिक मुझे टीम का प्रबंधन करने में "मदद" करने जा रहा था। और आपको क्या लगता है पहला बिंदु क्या था? हमारे सिस्टम में रिलेशनल डेटाबेस का उपयोग क्यों नहीं किया जाता है!

मैंने एक महीने बाद नौकरी छोड़ दी और एक सलाहकार के रूप में अपना करियर शुरू किया। यह मेरे द्वारा बनाया गया सबसे अच्छा करियर था। जिस कंपनी में मैंने नौकरी छोड़ी, वह अब मौजूद नहीं है। मुझे लगता है कि उन्होंने एक पैसा नहीं कमाया।

मैंने 90 के दशक में रिलेशनल डेटाबेस मार्केट को देखा। मैंने अन्य सभी भंडारण तकनीकों को देखा है, जैसे ऑब्जेक्ट डेटाबेस और बी पेड़ों पर डेटाबेस, पतित और मर जाते हैं। 20 के दशक में शराब बनाने वालों की तरह। 90 के दशक के अंत तक, केवल दिग्गज बच गए।

इन दिग्गजों ने एक लहर चलाई। वे देवता थे। उन्होंने शासन किया। डॉट-कॉम बबल के दौरान, उनमें से एक में एक टेलीविज़न विज्ञापन लॉन्च करने का दुस्साहस था, जिसमें दावा किया गया था कि उनकी प्रणाली "इंटरनेट को चलाने वाली शक्ति" थी। इसने मुझे 70 के दशक से बीयर के नारे की याद दिला दी - "मन्नो को पूरे बुलबुल को पकड़ना चाहिए जो मैं कर सकता हूं।" हे भगवान!

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

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

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

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

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

मैं BigTable, Mongo, CouchDB के रूप में मनोरंजन के साथ देखता था और 80 के दशक में छोटे ब्रुअरीज की तरह, अन्य प्यारे छोटे डेटाबेस सिस्टम विकसित होने लगे। बीयर वापस आ गया है! और यह स्वादिष्ट हो जाता है।

लेकिन फिर मैंने कुछ देखा। इन क्यूट, सिंपल, एलिगेंट नॉन-रिलेशनल डेटाबेस का इस्तेमाल करने वाले कुछ सिस्टम को डेटाबेस के आसपास डिजाइन किया गया है । स्पार्कलिंग नवीनता के ढांचे में लिपटे डेटाबेस अभी भी मूल में हैं! यह डिजाइनरों के दिमाग में है कि जहरीले संबंधपरक विज्ञापन बकवास है। वे अब भी एक घातक गलती करते हैं।

"रुको!" मैं चिल्लाया। - “रुको! आप समझे नहीं आप समझ नहीं सकते। ”लेकिन गति बहुत अच्छी थी। चौखटे की एक विशाल आकाशगंगा उत्पन्न हुई, यह हमारे उद्योग पर गिर गई और दुनिया पर कब्जा कर लिया। इन चौखटों ने डेटाबेस को चमकाया और आपके आवेदन के मूल को पकड़ने और पकड़ने के लिए संघर्ष किया। उन्हें डेटाबेस का प्रबंधन और सजाने के लिए बुलाया गया था। यह भी दावा किया गया था कि वे एक रिलेशनल डेटाबेस को NoSQL डेटाबेस में बदल सकते हैं। और रूपरेखा पूरी दुनिया को जोर से चिल्लाया: "मुझ पर भरोसा करो और मैं तुम्हें स्वतंत्र कर दूंगा!"।

इस लेख का शीर्षक "नॉट ए डीबी" है। शायद इन रंटों के बाद आपको संकेत मिला कि मैंने उसे क्यों बुलाया।

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

जब मैं एक डेवलपर को सुनता हूं तो मैं पागल हो जाता हूं कि वह "टॉमकैट विद स्प्रिंग एंड हाइबरनेट ऑन ओरेकल" की शैली में अपनी परियोजना का वर्णन करे। शब्दांकन ही चौखटे और डेटाबेस को सबसे आगे रखता है।

आपको क्या लगता है कि इस प्रणाली की वास्तुकला कैसी दिखती है? आप सोचते हैं
क्या आपको डिज़ाइन के मूल में उपयोग परिदृश्य मिलेंगे? या क्या आप पाएंगे कि सोर्स कोड फ्रेमवर्क मॉडल के साथ बेहतर रूप से फिट होने के लिए तैयार है? क्या आप ध्यान देते हैं कि व्यावसायिक वस्तुएँ संदिग्ध रूप से तालिकाओं की पंक्तियों से मिलती जुलती हैं? क्या पूरा डेटा स्कीमा और फ्रेमवर्क ओवरसाइज़ हो जाता है?

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

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

यदि आप NoSQL डेटाबेस का उपयोग करते हैं तो कुछ बदलना है? बिल्कुल नहीं! आप अभी भी यह सुनिश्चित करने पर ध्यान केंद्रित कर रहे हैं कि उपयोग के परिदृश्य रिकॉर्ड किए गए और मान्य हैं, डेटाबेस के बारे में सोचने से पहले भी डेटाबेस के प्रकार पर ध्यान नहीं दे रहे हैं।

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

आगे एक दिलचस्प समय है। एक समय जब विभिन्न भंडारण प्रौद्योगिकियों पर प्रतिबंध हटा दिया गया है, और हम कई नए तरीकों के साथ प्रयोग करने के लिए स्वतंत्र हैं। लेकिन CouchDB, Mongo और BigTable के साथ खेल के दौरान भी मत भूलना: डेटाबेस सिर्फ एक घटक है जिसे तत्काल समाधान की आवश्यकता नहीं है ।