डेटाबेस ट्रिगर पसंद नहीं है? आप बस यह नहीं जानते कि उनके साथ कैसे काम करना है!

बड़े रिलेशनल डेटाबेस को डिज़ाइन करते समय, हम अक्सर एक सामान्य रूप से अलग होने का निर्णय लेते हैं, यानी डीनॉर्मलाइज़ेशन।

इसके कारण अलग-अलग हो सकते हैं, जैसे निर्दिष्ट डेटा तक पहुंच को तेज करने का प्रयास, उपयोग किए गए प्लेटफॉर्म/फ्रेमवर्क/विकास उपकरणों की बाधाएं, और डेटाबेस डेवलपर/डिजाइनर के कौशल की कमी।

कड़ाई से बोलते हुए, ढांचे की बाधाओं आदि का संदर्भ वास्तव में कौशल की कमी को सही ठहराने का एक प्रयास है।

असामान्य डेटा एक भेद्यता है, जिसके माध्यम से हमारे डेटाबेस को एक गैर-संगत (गैर-अभिन्न) स्थिति में लाना आसान है।

हम इससे क्या कर सकते हैं?

उदाहरण

एक डेटाबेस में, कुछ वित्तीय कार्यों के साथ एक तालिका होती है:विभिन्न खातों पर धन की प्राप्ति और निपटान।

हमें हमेशा खाते की शेष राशि जानने की आवश्यकता होती है।

सामान्यीकृत डेटा में, फंड बैलेंस हमेशा एक परिकलित मूल्य होता है। हम बिना डेबिट किए कुल प्राप्तियों की गणना करने जा रहे हैं।

हालांकि, हर बार जब कई ऑपरेशन होते हैं तो शेष राशि की गणना करना बहुत महंगा होता है। इसलिए, वास्तविक शेष राशि को एक अलग तालिका में संग्रहीत करने का निर्णय लिया गया। हम इस तालिका में डेटा कैसे अपडेट करते हैं?

समाधान 'हमेशा की तरह' है

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

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

ट्रिगर

एक विकल्प के रूप में, ट्रिगर का उपयोग असामान्य डेटा की अखंडता को नियंत्रित करने के लिए किया जाता है।

मैंने सुना है कि ट्रिगर एक डेटाबेस को बहुत धीमा कर देते हैं, इसलिए उनका उपयोग करने का कोई मतलब नहीं है।

दूसरा तर्क यह था कि सभी तर्क एक अलग अनुप्रयोग में निहित हैं और व्यावसायिक तर्क को अलग-अलग स्थानों पर रखना अनुचित है।

आइए जानें।

लैग

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

ट्रिगर में 'भारी' क्वेरी का उदाहरण इस प्रकार है:

update totals 
set total = select sum(operations.amount) from operations where operations.account = current_account
where totals.account = current_account

एक क्वेरी संचालन . के साथ तालिका को संदर्भित करती है और कुल राशि का योग करता है खाते . के संचालन के लिए ।

जब डेटाबेस बढ़ता है, तो ऐसी क्वेरी अधिक से अधिक समय और संसाधनों का उपभोग करेगी। हालांकि, हम निम्न प्रकार की हल्की क्वेरी का उपयोग करके समान परिणाम प्राप्त कर सकते हैं:

update totals 
set total = totals.total + current_amount
where totals.account = current_account

एक नई पंक्ति जोड़ते समय, यह ट्रिगर बिना गणना किए ही खाते के कुल योग को बढ़ा देगा। कुल तालिका में डेटा राशि पर निर्भर नहीं करता है। फिर से कुल की गणना करने का कोई मतलब नहीं है, क्योंकि हम यह सुनिश्चित कर सकते हैं कि एक नया ऑपरेशन जोड़ते समय हर बार ट्रिगर सक्रिय होता है।

पंक्तियों को हटाने या संशोधित करने की प्रक्रिया उसी तरह की जाती है। इस प्रकार के ट्रिगर संचालन को धीमा नहीं करेंगे, हालांकि, डेटा युग्मन और अखंडता सुनिश्चित करेंगे।

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

व्यावसायिक तर्क

हमें उन कार्यों में अंतर करना चाहिए जो व्यावसायिक तर्क से डेटा अखंडता प्रदान करते हैं। प्रत्येक मामले में, मैं एक प्रश्न पूछता हूं कि यदि डेटा सामान्यीकृत किया गया था, तो क्या हमें ऐसे फ़ंक्शन की आवश्यकता होगी? यदि सकारात्मक है, तो कार्य व्यावसायिक तर्क है। यदि नकारात्मक है, तो कार्य डेटा अखंडता प्रदान करना है। आप इन कार्यों को ट्रिगर में लपेट सकते हैं।

हालाँकि, एक राय है कि DBMS के माध्यम से सभी व्यावसायिक तर्कों को लागू करना आसान है, जैसे PostgreSQL या Oracle।

मुझे उम्मीद है कि यह लेख आपकी सूचना प्रणाली में बग की संख्या को कम करने में मदद करेगा।

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

पी.एस.

• लेख में, मैंने एक शक्तिशाली उपकरण के रूप में ट्रिगर्स का उपयोग करने के एकमात्र पहलू पर ध्यान आकर्षित किया।
• लेख में वर्णित दृष्टिकोण ऑपरेशंस . में अनुक्रमणिका से बचने की अनुमति देता है तालिका, जो बदले में, इस तालिका में डेटा जोड़ने की प्रक्रिया को गति दे सकती है। उच्च मात्रा में, यह दृष्टिकोण आसानी से ट्रिगर पर खर्च किए गए समय की भरपाई करता है।
• यह समझना महत्वपूर्ण है कि हमें किन उपकरणों का उपयोग करने की आवश्यकता है। इस मामले में, आप कई मुद्दों से बचेंगे।