संग्रहित कार्य। पेशेवरों और विपक्ष

एक DBMS के संग्रहीत कार्यों का उपयोग करके व्यापार तर्क या उसके हिस्से को लागू करना हमेशा एक अड़चन ब्लॉक रहा है। एक तरफ, डीबीए बैरिकेड्स और डेटाबेस प्रोग्रामर, दूसरी तरफ, डेवलपर्स बैकएंड।
मैं दोनों शिविरों से क्रोध को भड़काने के लिए उद्यम करूंगा, लेकिन फिर भी पेशेवरों और विपक्षों को संक्षेप में बताऊंगा और अपने विचारों को बताऊंगा कि संग्रहीत कार्यों में कोड कब लिखना है और उन्हें कब निकालना है।




आइए इसके खिलाफ बहस शुरू करें:

धंधा करने का तर्क

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

डीबीएमएस भाषा की गरीबी

ऐसी बात है। आधुनिक सामान्य प्रयोजन की भाषाओं की तुलना में एचएफ पीएल / एसक्यूएल, टी-एसक्यूएल, पीएल / पीजीएससीएल लिखने के लिए पारंपरिक भाषाएं काफी आदिम हैं। यह ध्यान देने योग्य है कि एचएफ को अधिक उन्नत भाषाओं में लिखना संभव है, जैसे कि ओरेकल में जावा या पोस्टग्रैक्स्ल में पायथन।

संग्रहीत कार्यों के लिए असहिष्णुता

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

टीम के लिए आवश्यक कौशल की कमी और संबंधित विशेषज्ञों की उच्च "लागत"

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

अब पेशेवरों:

गति

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

डेटा संरचना छिपाना

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

लचीले अभिगम नियंत्रण

उस उपयोगकर्ता को प्रतिबंधित करने का अच्छा अभ्यास है जिसके तहत ग्राहक एप्लिकेशन डेटाबेस में इस तरह से "जाता है" कि उसे किसी भी ऑब्जेक्ट को पढ़ने और संशोधित करने का अधिकार नहीं है। केवल उसके लिए अनुमत कार्य करता है। इस प्रकार, यह कड़ाई से नियंत्रित करना संभव है कि क्लाइंट के लिए क्या क्रियाएं उपलब्ध हैं, क्लाइंट अनुप्रयोग त्रुटि के कारण डेटा अखंडता के उल्लंघन की संभावना कम हो जाती है।

कम संभावना SQL इंजेक्शन

क्लाइंट प्रोग्राम के किनारे से डायनेमिक SQL का उपयोग करते समय, क्लाइंट प्रोग्राम SQL DBMS कमांड्स को कोड में पहले बने स्ट्रिंग्स के रूप में प्रसारित करता है। इन पंक्तियों को बनाते समय, SQL कमांड के अनपेक्षित संशोधन की संभावना को रोकने के लिए प्रोग्रामर को बेहद सावधान रहने की आवश्यकता होती है। एचएफ एसक्यूएल का उपयोग करते समय, आवेदन पक्ष पर कोड आमतौर पर स्थिर होता है, और एक साधारण एचएफ कॉल की तरह दिखता है, जिनमें से पैरामीटर को पंक्तियों में नहीं, बल्कि प्लेसहोल्डर (: चर) के माध्यम से बाध्यकारी तंत्र के माध्यम से पारित किया जाता है। बेशक, यह एसक्यूएल इंजेक्शन की संभावना को पूरी तरह से बाहर नहीं करता है (आखिरकार, आप एचएफ में गतिशील रूप से निष्पादित एसक्यूएल क्वेरी के पाठ के साथ पैरामीटर द्वारा पारित स्ट्रिंग को संक्षिप्त करने का प्रबंधन कर सकते हैं), लेकिन इसकी संभावना को काफी कम कर देता है।

SQL पुन: उपयोग

संग्रहीत परत में डेटा के साथ काम करने के तर्क को लागू करने से, हमें SQL कोड का पुन: उपयोग करने के सामान्य पदानुक्रमित मॉडल मिलता है।
डायनेमिक SQL का उपयोग करते समय, प्रश्नों का पुन: उपयोग करना मुश्किल है।
उदाहरण के लिए, एचएफ पर आधारित सिस्टम ए और डायनामिक एसक्यूएल पर आधारित सिस्टम बी हो। दोनों प्रणालियों में get_price आइटम की कीमत पाने के लिए एक फ़ंक्शन है। मामले में, यह एक संग्रहीत कार्य या दृश्य है, अगर बी में, मान लें कि जावा में एक प्रक्रिया है जो जेडडीबीसी के माध्यम से एक SQL क्वेरी को निष्पादित करती है। एक कार्य है - स्टॉक में माल की कुल लागत प्राप्त करने के लिए। मामले ए में, हम get_price को सीधे उस क्वेरी में शामिल करते हैं जो वेयरहाउस में माल की सूची प्राप्त करता है (यदि get_price एक दृश्य या SQL HF है, जैसे कि PostgreSQL में, ऑप्टिमाइज़र इनलाइन क्वेरी का विस्तार करता है - यह एक क्वेरी में परिणाम प्राप्त करता है जो जल्दी से राशि पाता है) ।
मामले में, बी दो विकल्प हैं: या तो गोदाम में सामानों के चयन के साथ कर्सर चलाएं और get_price n बार कॉल करें (जिसका अर्थ है कि पूरे चयन को ग्राहक को नेटवर्क पर प्रेषित किया जाना चाहिए) या पुन: उपयोग के बारे में भूल जाएं और एक सब-डुप्लिकेट लिख दें जो पहले से ही था get_price में लिखा है। दोनों विकल्प खराब हैं।

आसान एसक्यूएल डिबगिंग

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

डेटाबेस में व्यावसायिक तर्क कब लिखें?

यदि डाटा प्रोसेसिंग की गति महत्वपूर्ण है

भंडारण के स्थान पर डेटा को सीधे संसाधित करना अक्सर प्रसंस्करण की गति में एक महत्वपूर्ण वृद्धि देता है। उदाहरण के लिए, उदाहरण के लिए, डेटा वेयरहाउस स्तर पर एकत्रीकरण संभव हो जाता है - सरणी से डेटा डीबीएमएस सर्वर पर स्थानांतरित नहीं किया जाता है, क्लाइंट का उल्लेख नहीं करना है।

जब डेटा अखंडता और स्थिरता महत्वपूर्ण हैं

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

डेटा में एक जटिल लेकिन अच्छी तरह से स्थापित संरचना है

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

कोड कब निकालना है?

बाहरी डेटा के साथ काम करें

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

परिष्कृत एल्गोरिदम

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

Highload

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

निष्कर्ष यह है कि कोई स्पष्ट एल्गोरिथ्म नहीं है। हर बार, निर्णय आर्किटेक्ट और प्रबंधक के साथ रहता है, और यह उस पर निर्भर करता है कि क्या परियोजना दौड़ की स्थिति और NoSQL डेटा की असंगति, ORM प्रश्नों के प्रदर्शन और डीबगिंग के साथ समस्याओं में फंस जाएगी या संग्रहीत कार्यों का उपयोग करके DBMSs को स्केल करने की समस्याओं के खिलाफ टिकी हुई है। इसलिए - सही निर्णय लें :)