कार्यात्मक इकाइयाँ

SQL मानक को लागू करने के अन्य पहलुओं की तरह, सटीक विवरण RDBMS से RDBMS में थोड़ा भिन्न होता है। सामान्य तौर पर:

• कार्य लेनदेन को नियंत्रित नहीं कर सकते।
• फ़ंक्शन मान लौटाते हैं; प्रक्रियाएं निर्दिष्ट पैरामीटर को संशोधित कर सकती हैं OUT या INOUT जिसे तब कॉलिंग संदर्भ में पढ़ा जा सकता है, लेकिन परिणाम कभी नहीं लौटाता (एसक्यूएल सर्वर को छोड़कर)।
• फ़ंक्शंस SQL ​​कथनों के भीतर से पुनर्प्राप्त या संग्रहीत किए जा रहे रिकॉर्ड पर कुछ कार्य करने के लिए आमंत्रित किए जाते हैं, जबकि प्रक्रियाएं अकेली होती हैं।

अधिक विशेष रूप से, MySQL फ़ंक्शन में पुनरावर्तन और कुछ अतिरिक्त SQL कथनों को भी अस्वीकार करता है। SQL सर्वर डेटा को संशोधित करने, गतिशील SQL निष्पादित करने और त्रुटियों को संभालने से कार्यों को प्रतिबंधित करता है। PostgreSQL ने 2017 तक संस्करण 11 के साथ संग्रहीत कार्यविधियों को फ़ंक्शंस से बिल्कुल अलग नहीं किया था, इसलिए Postgres फ़ंक्शंस लेन-देन नियंत्रण को छोड़कर, लगभग सभी प्रक्रियाओं को कर सकता है।

तो, कब किसका उपयोग करना है? फ़ंक्शंस तर्क के लिए सबसे उपयुक्त हैं जो रिकॉर्ड द्वारा रिकॉर्ड लागू होते हैं क्योंकि डेटा संग्रहीत और पुनर्प्राप्त किया जाता है। अधिक जटिल कार्यप्रवाह जो स्वयं द्वारा लागू किए जाते हैं और आंतरिक रूप से डेटा को स्थानांतरित करते हैं, प्रक्रियाओं के रूप में बेहतर होते हैं।

डिफ़ॉल्ट और पीढ़ी

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

CREATE TABLE pythag (  a INT NOT NULL,  b INT NOT NULL,  c DOUBLE PRECISION NOT NULL    GENERATED ALWAYS AS (sqrt(pow(a, 2) + pow(b, 2)))    STORED);
 

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

जेनरेट किए गए कॉलम एक विशेष उपकरण हैं। अधिक बार, यदि कोई मान डालने पर आपूर्ति नहीं की जाती है तो जो कुछ भी आवश्यक होता है वह डिफ़ॉल्ट होता है। now() . जैसे फंक्शन कॉलम डिफॉल्ट के रूप में बार-बार दिखाई देते हैं, लेकिन अधिकांश डेटाबेस कस्टम के साथ-साथ अंतर्निहित कार्यों की अनुमति देते हैं (MySQL को छोड़कर, जहां केवल current_timestamp एक डिफ़ॉल्ट मान हो सकता है)।

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

CREATE SEQUENCE lot_counter;CREATE OR REPLACE FUNCTION next_lot_number () RETURNS TEXT AS $$BEGIN  RETURN date_part('year', now())::TEXT ||    lpad(nextval('lot_counter'::REGCLASS)::TEXT, 2, '0');END;$$LANGUAGE plpgsql;CREATE TABLE lots (  lot_number TEXT NOT NULL DEFAULT next_lot_number () PRIMARY KEY,  current_quantity INT NOT NULL DEFAULT 0,  target_quantity INT NOT NULL,  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),  completed_at TIMESTAMPTZ,  CHECK (target_quantity > 0));
 

फ़ंक्शंस में डेटा का संदर्भ देना

उपरोक्त अनुक्रम दृष्टिकोण में एक महत्वपूर्ण कमजोरी है (और <पाठ> कम से कम एक कम महत्वपूर्ण ):नया साल आ गया, lot_counter अभी भी वही मान होगा जो 31 दिसंबर को था। हालांकि, एक वर्ष में कितने लॉट बनाए गए हैं, और lots को क्वेरी करके ट्रैक करने के एक से अधिक तरीके हैं। स्वयं next_lot_number फ़ंक्शन वर्ष समाप्त होने के बाद सही मान की गारंटी दे सकता है।

CREATE OR REPLACE FUNCTION next_lot_number () RETURNS TEXT AS $$BEGIN  RETURN (    SELECT date_part('year', now())::TEXT || lpad((count(*) + 1)::TEXT, 2, '0')    FROM lots    WHERE date_part('year', created_at) = date_part('year', now())  );END;$$LANGUAGE plpgsql;ALTER TABLE lots  ALTER COLUMN lot_number SET DEFAULT next_lot_number();
 

कार्यप्रवाह

यहां तक ​​​​कि एक सिंगल-स्टेटमेंट फ़ंक्शन का बाहरी कोड पर एक महत्वपूर्ण लाभ होता है:निष्पादन डेटाबेस की एसीआईडी ​​​​गारंटी की सुरक्षा को कभी नहीं छोड़ता है। तुलना करें next_lot_number क्लाइंट एप्लिकेशन या यहां तक ​​कि मैन्युअल प्रक्रिया की संभावनाओं के ऊपर, एक SQL कथन executing निष्पादित करना इस वर्ष अब तक लॉट की संख्या का मिलान करने के लिए उसके बाद एक सेकंड जो नया लॉट सम्मिलित करता है। अगर ऑर्डर काफी तेजी से दिए जा रहे हैं, तो गिनती और डालने के बीच आपके नीचे लॉट की संख्या बदल सकती है।

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

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

जैसा कि ऊपर उल्लेख किया गया है, यह एक ऐसा क्षेत्र है जहां RDBMS फ्लेवर और SQL बोलियों के बीच अंतर सामने आता है। एक डेटाबेस के लिए विकसित एक फ़ंक्शन या प्रक्रिया शायद बिना किसी बदलाव के दूसरे पर नहीं चलेगी, चाहे वह SQL सर्वर के TOP को प्रतिस्थापित कर रहा हो एक मानक LIMIT . के लिए क्लॉज या पूरी तरह से फिर से काम करना कि कैसे अस्थायी स्थिति को एंटरप्राइज़ Oracle में PostgreSQL माइग्रेशन में संग्रहीत किया जाता है। SQL में अपने वर्कफ़्लोज़ को कैननाइज़ करना भी आपको आपके वर्तमान प्लेटफ़ॉर्म पर ले जाता है और आपके द्वारा किए जाने वाले लगभग किसी भी अन्य विकल्प की तुलना में अधिक अच्छी तरह से बोली लगाता है।

प्रश्नों में गणना

अब तक हमने डेटा को संग्रहीत और संशोधित करने के लिए फ़ंक्शंस का उपयोग करने पर ध्यान दिया है, चाहे वह तालिका परिभाषाओं के लिए बाध्य हो या बहु-तालिका वर्कफ़्लो का प्रबंधन। एक अर्थ में, यह अधिक शक्तिशाली उपयोग है जिसके लिए उन्हें रखा जा सकता है, लेकिन कार्यों का डेटा पुनर्प्राप्ति में भी एक स्थान है। आपके द्वारा अपनी क्वेरी में पहले से उपयोग किए जा सकने वाले कई टूल मानक बिल्ट-इन जैसे count . से फ़ंक्शन के रूप में कार्यान्वित किए जाते हैं Postgres' jsonb_build_object . जैसे एक्सटेंशन के लिए , PostGIS' ST_SnapToGrid , और अधिक। बेशक, चूंकि वे डेटाबेस के साथ अधिक मजबूती से एकीकृत होते हैं, वे ज्यादातर SQL के अलावा अन्य भाषाओं में लिखे जाते हैं (जैसे PostgreSQL और PostGIS के मामले में C)।

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

यह कहा जाना चाहिए:यदि आप किसी एप्लिकेशन बैकएंड के साथ काम कर रहे हैं, तो इसकी डेटा एक्सेस टूलकिट सीमित कर सकती है कि फ़ंक्शन के साथ क्वेरी परिणामों को बढ़ाने से आपको कितना लाभ मिलता है। ऐसे अधिकांश पुस्तकालय मनमाने ढंग से SQL निष्पादित कर सकते हैं, लेकिन जो मॉडल वर्गों के आधार पर सामान्य SQL कथन उत्पन्न करते हैं वे क्वेरी को अनुकूलित करने की अनुमति दे सकते हैं या नहीं SELECT सूचियाँ। जेनरेट किए गए कॉलम या दृश्य यहां एक उत्तर हो सकते हैं।

ट्रिगर और परिणाम

डेटाबेस डिजाइनरों और उपयोगकर्ताओं के बीच कार्य और प्रक्रियाएं काफी विवादास्पद हैं, लेकिन चीजें वास्तव में ट्रिगर्स के साथ उतारें। एक ट्रिगर एक स्वचालित क्रिया को परिभाषित करता है, आमतौर पर एक प्रक्रिया (SQLite केवल एक ही कथन की अनुमति देता है), पहले, बाद में, या किसी अन्य क्रिया के बजाय निष्पादित करने के लिए।

आरंभिक क्रिया आम तौर पर एक तालिका में एक सम्मिलित, अद्यतन या हटाई जाती है, और ट्रिगर प्रक्रिया को आमतौर पर प्रत्येक रिकॉर्ड के लिए या संपूर्ण रूप से कथन के लिए निष्पादित करने के लिए सेट किया जा सकता है। SQL सर्वर भी अद्यतन करने योग्य दृश्यों पर ट्रिगर की अनुमति देता है, ज्यादातर अधिक विस्तृत सुरक्षा उपायों को लागू करने के तरीके के रूप में; और यह, PostgreSQL, और Oracle सभी किसी न किसी प्रकार के ईवेंट या DDL . की पेशकश करते हैं ट्रिगर जो डेटाबेस संरचना में परिवर्तन पर प्रतिक्रिया कर सकता है।

ट्रिगर के लिए एक सामान्य कम जोखिम वाला उपयोग अमान्य डेटा को संग्रहीत होने से रोकने के लिए एक अतिरिक्त-शक्तिशाली बाधा के रूप में है। सभी प्रमुख रिलेशनल डेटाबेस में, केवल प्राथमिक और विदेशी कुंजियाँ और UNIQUE बाधाएं उम्मीदवार रिकॉर्ड के बाहर की जानकारी का मूल्यांकन कर सकती हैं। तालिका परिभाषा में यह घोषित करना संभव नहीं है कि, उदाहरण के लिए, एक महीने में केवल दो लॉट बनाए जा सकते हैं - और सबसे सरल डेटाबेस-और-कोड समाधान एक समान दौड़ की स्थिति के लिए कमजोर है जैसे कि गिनती-फिर-सेट दृष्टिकोण lot_number ऊपर। किसी भी अन्य बाधा को लागू करने के लिए जिसमें संपूर्ण तालिका, या अन्य तालिकाएं शामिल हैं, आपको एक ट्रिगर . की आवश्यकता है रिकॉर्ड के दायरे से बाहर देखने के लिए:

CREATE FUNCTION enforce_monthly_lot_limit () RETURNS TRIGGERAS $$DECLARE current_count BIGINT;BEGIN  SELECT count(*) INTO current_count  FROM lots  WHERE date_trunc('month', created_at) = date_trunc('month', NEW.created_at);  IF current_count >= 2 THEN    RAISE EXCEPTION 'Two lots already created this month';  END IF;  RETURN NEW;END;$$LANGUAGE plpgsql;CREATE TRIGGER monthly_lot_limitBEFORE INSERT ON lotsFOR EACH ROWEXECUTE PROCEDURE enforce_monthly_lot_limit();
 

एक बार जब आप DML को क्रियान्वित करना शुरू कर देते हैं और प्रवाह नियंत्रण का उपयोग करते हुए, यह कदमों के अधिक जटिल अनुक्रमों को किक करने और अभी भी अन्य तालिकाओं को शामिल करने के दायरे का विस्तार करने के लिए एक हॉप स्किप और जंप है। शायद एक रिकॉर्ड को lots . में सम्मिलित करना orders . में डालने से शुरू किए गए ट्रिगर का अंतिम संचालन स्वयं ही हो सकता है , किसी भी मानव उपयोगकर्ता या एप्लिकेशन बैकएंड को lots . पर लिखने का अधिकार नहीं है सीधे। या items . के रूप में बहुत कुछ जोड़ा जाता है, वहां एक ट्रिगर current_quantity . को अपडेट करना संभाल सकता है , और कुछ अन्य प्रक्रिया शुरू करें जब यह target_quantity . तक पहुंच जाए ।

ट्रिगर और फ़ंक्शन अपने निश्चित के एक्सेस स्तर पर चल सकते हैं (PostgreSQL में, एक SECURITY DEFINER किसी फ़ंक्शन के LANGUAGE . के बगल में घोषणा ), जो अन्यथा सीमित उपयोगकर्ताओं को व्यापक-श्रेणी की प्रक्रियाओं को आरंभ करने की शक्ति देता है -- और उन प्रक्रियाओं को मान्य और परीक्षण करना और भी महत्वपूर्ण बनाता है।

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

व्यावहारिक प्रोग्रामयोग्यता

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

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