🧕🏿 ☑️ ❣️ डेटाबेस के साथ काम करने के लिए एंटीपैटर्न 🥑 😇 🏸

हेलो, हेब्र! मैं आपको अपने लेख "डेटाबेस: एंटी-पैटर्न" का अनुवाद प्रस्तुत करता हूं ।

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

सिलिकॉन वैली, सीजन 2, एपिसोड 8 ।

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

यहाँ सिर्फ वे हैं जो तुरंत दिमाग में आते हैं।

बैकअप की कमी

"बैकअप करें" उन नियमों में से एक है (जैसे "रूट के तहत काम नहीं करते हैं" या "अपनी सीट बेल्ट को तेज़ करें") जिसमें से हम में से कई लोग सहमत हैं, लेकिन उनका पालन नहीं करते हैं, यह उम्मीद करते हैं कि बुरी चीजें दूसरों के साथ होती हैं और हमारे लिए नहीं।

वैसे, यदि आप बैकअप से रिकवरी का परीक्षण नहीं कर रहे हैं, तो आप मान सकते हैं कि आपके पास बैकअप बिल्कुल नहीं है। दूसरों की गलतियों से सीखें :

दूसरे शब्दों में, पाँच बैकअप तकनीकों में, कोई भी मज़बूती से काम नहीं करता है या कॉन्फ़िगर नहीं किया जाता है। अंत में, हमने 6 घंटे पहले किए गए बैकअप से डेटा को पुनर्स्थापित किया।

हमने GitLab.com के साथ 6 घंटे (मुद्दों, मर्ज अनुरोधों, उपयोगकर्ताओं, टिप्पणियों, स्निपेट्स, आदि) में डेटाबेस डेटा खो दिया है।

NoSQL

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

लेकिन आप Google नहीं हैं । कुछ सौ गीगाबाइट "बड़ा डेटा" नहीं है, लेकिन प्रति दिन 1000 टिप्पणियां "उच्च भार" नहीं है। सबसे अधिक संभावना है PostgreSQL आपके डेटा के लिए पर्याप्त है। देखें: यह JSON को भी सपोर्ट करता है और इसे इंडेक्स कर सकता है ।

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

बहुत ढीली योजना

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

प्राकृतिक प्राथमिक कुंजी

कल्पना करें कि हम उपयोगकर्ताओं को संग्रहीत करना चाहते हैं, जिनमें से प्रत्येक के पास एक विशिष्ट ई-मेल होना चाहिए। सबसे स्पष्ट समाधान userएक स्तंभ के साथ एक तालिका बनाना है email, जो प्राथमिक कुंजी भी होगी।

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

लॉजिक इन स्टोरेज

मुझे यह दो कारणों से पसंद नहीं है:

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

पर्यावरण-विशिष्ट माइग्रेशन स्क्रिप्ट

मुझे पता है कि कभी-कभी कोई विकल्प नहीं होता है, लेकिन सामान्य तौर पर यह सुनिश्चित करने के लिए प्रयास करना बेहतर होता है कि सभी वातावरण (देव, परीक्षण, ठेस, आदि) यथासंभव समान हैं। वातावरण के बीच अंतर जितना अधिक होता है, उतनी ही अधिक संभावना होती है कि वह गलती करता है और उसे केवल ठेस पर पाता है।

आमतौर पर भी डीएमएल स्क्रिप्ट सार्वभौमिक हो सकती है। विभिन्न योजनाएं, अधिक बार नहीं, शुद्ध बुराई हैं।

इसलिए, जब मैं लिबास स्क्रिप्ट में पर्यावरण-विशिष्ट लेबल देखता हूं, तो मैं मारना चाहता हूं।

सहिष्णु प्रवासन लिपियों

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

गैर-परमाणु अद्यतन

मान लीजिए कि आप उत्पादन के आधार पर परिवर्तन चलाते हैं और प्रवास सफल नहीं हुआ। आप कुछ ठीक कर रहे हैं और फिर से कोशिश करना चाहते हैं। क्या ये काम करेगा? क्या होगा यदि कुछ परिवर्तनकारी संचालन किए जाते हैं, जबकि अन्य नहीं हैं?

आप देख सकते हैं कि यह वास्तव में एक कहानी है कि changeset होना चाहिए idempotent , और आप सही हो जाएगा।

दुर्भाग्य से, कई डेवलपर्स, बेकारपन के बारे में सोच रहे हैं, उपयोग IF NOT EXISTSया ऐसा कुछ। पिछले अनुभाग में, मैंने समझाया कि यह बुराई क्यों है।

इसके बजाय, परिवर्तनशील परमाणु बनाओ । फिर, एक त्रुटि के मामले में, किए गए परिवर्तनों को वापस रोल किया जाएगा और आपको इस परिवर्तन के बाद के आवेदन के साथ कोई समस्या नहीं होगी।

लेकिन लेनदेन पर भरोसा करते समय सावधान रहें। उदाहरण के लिए,MySQL लेनदेन में DDL अभिव्यक्तियों के लिए समर्थन अंधेरा और भयावहता से भरा है , इसलिए जब मैं MySQL के लिए Liquibase स्क्रिप्ट लिखता हूं तो मैं हमेशा प्रत्येक DDL अभिव्यक्ति के लिए एक अलग बदलाव करता हूं।

आपने कौन-कौन सी चींटियों को देखा है?

डेटाबेस के साथ काम करने के लिए एंटीपैटर्न