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