एक वेब-प्रोजेक्ट पर काम के प्रारंभिक चरण में एक डेटाबेस के निर्माण के बारे में एक दृष्टिकोण

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

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

1. विचार के आधार पर, आधार को डिज़ाइन किया गया है - जैसा कि बाद में यह पहली बार अनुमानित रूप से निकला। प्रत्येक सूचना इकाई की एक अलग तालिका है। प्रत्येक विशेषता का अपना क्षेत्र है।
2. परियोजना का कुछ हिस्सा प्राप्त आधार के आधार पर बनाया गया था। तर्क लागू किया जाता है, लेआउट बढ़ाया जाता है।
3. ग्राहक के साथ परामर्श (या "आंतरिक ग्राहक")। यहां यह पता चला है कि सब कुछ बदलने की जरूरत है। चूंकि दो दिन पहले हमारे पास जो जानकारी थी वह पुरानी थी, हमें ऐसी विशेषताएं मिलीं जिनके बारे में हमें संदेह भी नहीं था। यह स्थिति बहुत सामान्य है, क्योंकि कुछ लोग पूरी प्रक्रिया आरेख बनाने के लिए खुद को परेशानी देते हैं।
4. डेटाबेस स्कीमा का कुछ हिस्सा बदलें - सरलतम मामले में, आपको फ़ील्ड जोड़ने / निकालने की आवश्यकता होगी। इसके बाद, सभी SQL क्वेरी को बदलें। और इस मामले में तीसरा आवश्यक कदम नई शर्तों के तहत परीक्षण है।

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

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

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

आपको कभी भी NoSQL स्टोरेज से नियमित टेबल पर स्विच करने की आवश्यकता क्यों होगी? मेरे लिए, यह प्रश्न आसानी से हल हो गया है: जबकि मैं खुद को MongoDB का विशेषज्ञ नहीं कह सकता हूं या ऐसा कुछ नहीं है, वाणिज्यिक विकास के लिए यह साबित साधनों का उपयोग करना बेहतर है। हालाँकि, यदि आपके पास कोई विकल्प है और अगर हमारे पास प्रोजेक्ट में विश्लेषकों का कोई कर्मचारी नहीं है (जो हमारे डेटाबेस में SELECT * लिखते हैं) और तीसरे पक्ष की सेवाएं हमारे डेटाबेस का उपयोग नहीं करेंगी, तो सभी संग्रहण को NoSQL पटरियों पर बिल्कुल भी स्थानांतरित किया जा सकता है।

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

यहाँ मेरा कहना है।