अराजकता की कल्पना करें, आप NeonDB में 0.5 जीबी स्टोरेज के साथ एक मुफ्त डेटाबेस बनाते हैं और सोचते हैं, "अच्छा है, मैं परीक्षण के लिए एक मुफ्त टियर का उपयोग करूंगा" . फिर, घंटों बाद, घातक ईमेल आता है: "आपका भंडारण ख़त्म हो गया है!"। वाह, आपका क्या मतलब है? कुर्सी गर्म करने का भी समय नहीं था! उत्तर? मैंने शानदार प्रिज्मा ओआरएम का उपयोग किया और, सुधार करने के लिए, मैंने स्कीमा को मॉडलिंग करते हुए, दिन भर में कई माइग्रेट चलाए।

आइए समझें कि क्या हुआ और निश्चित रूप से, क्यों कभी-कभी अच्छा पुराना SQL अभी भी एक हजार गुना बेहतर होता है।

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

प्रिज्मा ओआरएम: सरल लेकिन महंगा

प्रिज्मा वह चीज है जो परफेक्ट लगती है। "मैं डेटाबेस प्रश्नों को हल करने जा रहा हूं, समय बचाऊंगा, यह नया प्रचार है।" पर आश्चर्य! कोई निःशुल्क दोपहर का भोजन नहीं है, और यह रंगो टोस्टेड स्टोरेज के रूप में आया है। मैंने दिन के दौरान migrates चलाया, और यह नियोन्डब पर भारी था। और यह कोई बहुत बड़ा प्रोजेक्ट भी नहीं था।

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

प्रिज्मा बहुत अच्छा है, लेकिन जब भंडारण की बात आती है, तो यह सब कुछ करना पसंद करता है:

1. राउंड माइग्रेशन: हर बार जब मैं माइग्रेट चलाता था, प्रिज्मा नए माइग्रेशन बनाता और संग्रहीत करता था। प्रत्येक के पास मेटाडेटा, लॉग और तालिकाओं का अपना छोटा पैकेज है।

2. लॉग जो गुणा करते हैं: यह सुनिश्चित करने के लिए कि कुछ भी गलत न हो (या ऐसा होने पर आपके जीवन को आसान बनाने के लिए), प्रिज्मा विस्तृत लॉग रिकॉर्ड करता है। लेकिन ये लॉग जमा हो जाते हैं और, चूंकि मैं "असीमित" बैंक पर नहीं हूं, इसलिए ये जल्द ही एक समस्या बन जाते हैं।

3. सहायक तालिकाओं के साथ ओवरलोडिंग: माइग्रेशन के अलावा, प्रिज्मा विभिन्न चीज़ों पर नज़र रखने के लिए अतिरिक्त तालिकाएँ भी बनाता है, विशेष रूप से रिलेशनल डेटाबेस में, जैसे कि पोस्टग्रेज।

अंत में, जो जीवन को सरल बनाने के लिए एक जादुई उपकरण की तरह लग रहा था, उसने मेरा मुफ़्त NeonDB खा लिया।

एसक्यूएल "ना नेल": कम अधिक क्यों है

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

1. पूर्ण नियंत्रण: बिल में कोई आश्चर्य नहीं है। आप ठीक-ठीक जानते हैं कि कोड की प्रत्येक पंक्ति क्या कर रही है और आपको लॉग या छिपी हुई तालिकाएँ आपके स्थान को बर्बाद नहीं करती मिलेंगी।

2. नो डेड वेट: डायरेक्ट एसक्यूएल का उपयोग करते हुए, आप जो लिखते हैं वही बैंक में जाता है। कोई मेटाडेटा, माइग्रेशन या लॉग जोखिम कम नहीं कर रहा है।

3. अधिक प्रदर्शन: डायरेक्ट एसक्यूएल, जब अच्छी तरह से किया जाता है, तो बहुत कम जगह और संसाधनों की खपत करता है। यह उन लोगों के लिए NeonDB जैसे छोटे बैंकों के लिए आदर्श है जो मेरे जैसे फ्रीगनिस्ट हैं।

4. कोई छिपा हुआ व्यवसाय नहीं: स्क्रैच या ढेर लगे लेन-देन लॉग से कोई तालिका नहीं बनाई गई। नियंत्रण आपका है, और केवल आपका है।

कहानी की नीति:

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

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