माइक्रोसॉफ्ट टी-एसक्यूएल ट्रिगर डिजाइन करना

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

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

आइए नियमों पर विचार करें…

नियम #1:ट्रिगर का उपयोग न करें!

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

डिफ़ॉल्ट रूप से, हमें पहले संग्रहित प्रक्रियाओं या विचारों को लिखना चाहिए। अधिकांश परिदृश्यों के लिए, वे ठीक काम करेंगे। आइए यहां जादू न जोड़ें।

तो फिर ट्रिगर पर लेख क्यों?

क्योंकि ट्रिगर्स के अपने उपयोग होते हैं। हमें यह पहचानने की जरूरत है कि हमें ट्रिगर्स का उपयोग कब करना चाहिए। हमें उन्हें इस तरह से लिखने की भी ज़रूरत है कि यह हमें चोट पहुँचाने से ज़्यादा हमारी मदद करे।

नियम #2:क्या मुझे वास्तव में ट्रिगर की आवश्यकता है?

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

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

तो हमें वास्तव में कब ट्रिगर की आवश्यकता होगी?

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

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

नियम #3:ट्रिगर सेट-आधारित होना चाहिए, न कि पंक्ति-आधारित

ट्रिगर के साथ अब तक की सबसे आम गलती यह है कि इसे पंक्तियों पर चलाना है। अक्सर हम इसके समान कोड देखते हैं:

--बैड कोड! उपयोग न करें! ट्रिगर डीबीओ बनाएं। कुछ ट्रिगरॉन डीबीओ। कुछ टेबल डालने के बाद @NewTotal पैसा; घोषणा @NewID int; शीर्ष 1 चुनें @NewID =SalesOrderID, @NewTotal =SalesAmount से सम्मिलित किया गया; अद्यतन dbo.SalesOrder SET OrderTotal =OrderTotal + @NewTotal जहाँ SalesOrderID =@SalesOrderIDEND;

सस्ता केवल यह तथ्य होना चाहिए कि एक टेबल . से एक SELECT TOP 1 था डाला। यह केवल तब तक काम करेगा जब तक हम केवल एक पंक्ति सम्मिलित करते हैं। लेकिन जब यह एक से अधिक पंक्तियाँ हों, तो उन अशुभ पंक्तियों का क्या होता है जो दूसरी और बाद में आती हैं? हम ऐसा कुछ करके उसमें सुधार कर सकते हैं:

--अभी भी खराब कोड! उपयोग न करें! ट्रिगर डीबीओ बनाएं। कुछ ट्रिगरॉन डीबीओ। कुछ टेबल डालने के बाद डीबीओ में विलय करें। बिक्री ऑर्डर के रूप में उपयोग किया जाता है जैसे कि मैं एस.सेल्स ऑर्डर आईडी =i.सेल्स ऑर्डर आईडी से मेल खाता हूं जब अपडेट सेट ऑर्डरटोटल =ऑर्डरटोटल;> 

 यह अब सेट-आधारित है और इस प्रकार बहुत सुधार हुआ है लेकिन इसमें अभी भी अन्य समस्याएं हैं जिन्हें हम अगले कुछ नियमों में देखेंगे…
 

 नियम #4:इसके बजाय एक दृश्य का उपयोग करें। 
 

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

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

 
 

 नियम #5:ट्रिगर सरल होना चाहिए। 
 

 डिबगिंग और संग्रहीत कार्यविधि के परीक्षण के बारे में टिप्पणी याद रखें? हम अपने आप पर सबसे अच्छा एहसान कर सकते हैं कि व्यापार तर्क को एक संग्रहीत प्रक्रिया में रखा जाए और इसके बजाय ट्रिगर को इसे लागू किया जाए। आपको कभी भी व्यावसायिक तर्क को सीधे ट्रिगर में नहीं लिखना चाहिए; जो प्रभावी रूप से डेटाबेस पर कंक्रीट डाल रहा है। यह अब आकार में जम गया है और तर्क का पर्याप्त रूप से परीक्षण करना समस्याग्रस्त हो सकता है। आपके परीक्षण दोहन में अब आधार तालिका में कुछ संशोधन शामिल होना चाहिए। यह सरल और दोहराने योग्य परीक्षण लिखने के लिए अच्छा नहीं है। यह सबसे जटिल होना चाहिए क्योंकि आपके ट्रिगर को इसकी अनुमति दी जानी चाहिए:
 
ट्रिगर बनाएं [डीबीओ]। जैसा कि मैं t.SomeID =i.someID पर मिलान करता हूं तो अद्यतन सेट t.SomeStuff =i.SomeStuff, t.OtherStuff =i.OtherStuff जब मेल नहीं खाता है तो INSERT (कुछ सामग्री, अन्य सामग्री) मान (i.someStuff, i.OtherStuff) आउटपुट डाला गया। कुछ आईडी में @ कुछ आईडी (कुछ आईडी); dbo से हटाएँ। कुछ आईडी); EXEC dbo.uspUpdateSomeStuff @SomeIDs;END;
 

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

 
 

 नियम #6:जब भी संभव हो ट्रिगर निष्क्रिय होना चाहिए। 
 

 सामान्यतया, ट्रिगर जरूरी निर्बल हो। यह तालिका-आधारित या दृश्य-आधारित ट्रिगर की परवाह किए बिना लागू होता है। यह विशेष रूप से उन लोगों पर लागू होता है जिन्हें बेस टेबल पर डेटा को संशोधित करने की आवश्यकता होती है जहां से ट्रिगर निगरानी कर रहा है। क्यों? क्योंकि अगर मनुष्य डेटा को संशोधित कर रहे हैं जो ट्रिगर द्वारा उठाया जाएगा, तो उन्हें एहसास हो सकता है कि उन्होंने गलती की है, इसे फिर से संपादित किया है या शायद उसी रिकॉर्ड को संपादित करें और इसे 3 बार सहेज लें। वे खुश नहीं होंगे यदि वे पाते हैं कि रिपोर्ट हर बार एक संपादन करने पर बदल जाती है जो रिपोर्ट के आउटपुट को संशोधित करने वाला नहीं है।
 

 अधिक स्पष्ट होने के लिए, ऐसा कुछ करके ट्रिगर को अनुकूलित करने का प्रयास करना आकर्षक हो सकता है:
 
सोर्सडाटा एएस के साथ (ऑर्डर आईडी चुनें, एसयूएम (सेल्सअमाउंट) न्यूसेल के रूप में ऑर्डर आईडी द्वारा सम्मिलित ग्रुप से कुल) डीबीओ में मर्ज करें। सोर्सडेटा के रूप में बिक्री ऑर्डर के रूप में ओ। ऑर्डर आईडी =डी। ऑर्डर आईडी जब मिलान किया गया तो अपडेट सेट ओ। ऑर्डरटोटल =ओ। ऑर्डरटोटल =ओ। ऑर्डरटोटल + d.NewSaleTotal;
 

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

 अब तक, आपको यह देखना चाहिए कि क्यों नियम #4 संग्रहीत कार्यविधि में केवल प्राथमिक कुंजियों को बाहर धकेल कर हमारी मदद करता है, बजाय इसके कि किसी डेटा को संग्रहीत कार्यविधि में भेजने का प्रयास किया जाए या इसे सीधे ट्रिगर के अंदर किया जाए जैसा कि नमूना ने किया होगा ।
 

 इसके बजाय, हम चाहते हैं कि एक संग्रहीत कार्यविधि में इसके समान कुछ कोड हो:
 
प्रक्रिया बनाएं dbo.uspUpdateSalesTotal ( @SalesOrders SalesOrderTableType READONLY) ASBEGIN सोर्सडेटा AS के साथ (चुनें s.OrderID, SUM(s.SalesAmount) जैसे NewSaleTotal dbo से। .SalesOrderID =s.SalesOrderID ) Group by OrderID ) dbo में मर्ज करें। o.OrderID =d.OrderID के रूप में स्रोत डेटा का उपयोग करते हुए o.OrderID =d.OrderID जब मिलान किया गया तो अद्यतन सेट o.OrderTotal =d.NewSale>END;END; 

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

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

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

  
 

 
 

 रैप अप करना 
 

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

 यदि आपके पास साझा करने के लिए कोई और सुझाव या नियम हैं, तो टिप्पणियों में लिखें!