क्या मुझे वास्तव में रिलेशनल डेटाबेस के लिए ट्रिगर की आवश्यकता है, उदाहरण के लिए, PostgreSQL?

Question

मुझे पता है कि डेटाबेस को सुसंगत रखने के लिए संग्रहीत डेटा को मान्य करने के लिए ट्रिगर्स का उपयोग किया जा सकता है। हालाँकि, डेटाबेस में संग्रहीत करने से पहले आवेदन पक्ष पर डेटा का सत्यापन क्यों नहीं किया जाता है?

उदाहरण के लिए, हम ग्राहकों को संग्रहीत करते हैं, और हम कुछ सत्यापन करना चाहते हैं जो डीडीएल स्तर पर आसानी से नहीं किया जा सकता है। https://severalnines.com/blog/postgresql-triggers-and-stored-function-basics

एक और उदाहरण ऑडिट का है।

अपडेट करें

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

Comments

However, why not perform validation of data on the application side before storing them into the database?खैर, ये दोनों परस्पर अनन्य नहीं हैं। यह संभावना है कि आप दोनों पक्षों की विभिन्न चीजों को मान्य करेंगे। जबकि आवेदन पक्ष पर सत्यापन व्यवसाय-केंद्रित हैं, डेटाबेस पर सत्यापन अधिक डेटा-केंद्रित हैं। कई और विभिन्न अनुप्रयोगों द्वारा खिलाए गए डेटाबेस में सोचें।

— Laiv

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

— ग्रेग बरगार्ड

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

— डॉक्टर ब्राउन

@GregBurghardt अधिकांश डेटाबेस में ऐसे कथन होते हैं जिनका उपयोग उन प्रकार की गतिविधियों के लिए ट्रिगर अक्षम करने के लिए किया जा सकता है।

— ब्लर एफएल

@ बेलरफ: हाँ, लेकिन आपको इस बात से अवगत होना चाहिए कि उन ट्रिगर को सभी कनेक्टेड उपयोगकर्ताओं के लिए अस्थायी रूप से अक्षम किया जा सकता है, जब आप केवल चालू सत्र के लिए उन चेक को सशर्त रूप से अक्षम करना चाहते हैं।

— ग्रेग बरगार्ड

Answer 1

यह इस बात पर निर्भर करता है कि आप किस प्रकार की एप्लिकेशन प्रणाली का निर्माण कर रहे हैं:

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

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

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

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

इस पुराने एसई पोस्ट को भी देखें: डेटाबेस की सफाई के लिए एप्लीकेशन लॉजिक बनाम डीबी ट्रिगर

इसलिए अपने लिए तय करें कि आप किस तरह की प्रणाली का निर्माण कर रहे हैं, तो आप एक स्थापित निर्णय ले सकते हैं कि ट्रिगर्स आपके मामले के लिए सही उपकरण हैं या नहीं।

Answer 2

मुझे लगता है कि सवाल डेटा की गुणवत्ता के लिए जिम्मेदारी के बारे में है।

उत्तर इस बात पर निर्भर करता है कि आप सिस्टम को कैसे देखते हैं।

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

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

दोनों ही विचारों में अगला सवाल यह है कि डेटाबेस के उपयोग को या तो फैंसी फाइल के रूप में, या एक अलग सेवा का समर्थन कैसे किया जाए। आप इसे हासिल कर सकते हैं:

• डेटाबेस प्लेटफ़ॉर्म को तालिकाओं / विचारों / संग्रहीत प्रक्रियाओं / ट्रिगर / आदि के रूप में प्रदान करने वाले उपकरणों का उपयोग करना ...
• डेटाबेस को एक्सेस करने के लिए सभी क्लाइंट को एक सेवा के भीतर ही लपेट देना चाहिए
• डेटाबेस को उस लाइब्रेरी में लपेटना जो डेटा तक पहुंचने के लिए सभी ग्राहकों द्वारा उपयोग की जानी चाहिए।

प्रत्येक अपने स्वयं के पेशेवरों / विपक्षों के साथ आता है और सिस्टम के भीतर काम करने वाले पर्यावरण के वास्तु बाधाओं पर निर्भर करेगा।

इसके बावजूद कि आप जो भी देखते हैं वह हमेशा सीमाओं पर डेटा को मान्य करने के लिए भुगतान करता है।

• UI पर फ़ील्ड्स को मान्य करें जो एक उपयोगकर्ता प्रवेश करता है
• क्लाइंट को छोड़ने से पहले नेटवर्क / एपीआई अनुरोध को मान्य करें
• कुछ भी करने से पहले सर्वर में नेटवर्क / एपीआई अनुरोध को मान्य करें
• डेटा को व्यावसायिक नियमों में पारित किया जाए
• जारी रहने से पहले डेटा को मान्य करें
• दृढ़ता से प्राप्त होने के बाद डेटा को मान्य करें
• इतने पर और इतने पर

प्रत्येक सीमा पर कितना सत्यापन किया जाता है यह इस बात पर निर्भर करता है कि इसे मान्य नहीं करना कितना जोखिम भरा है।

• दो संख्याओं को एक साथ गुणा करना?
  • आपको गलत नंबर मिलता है क्या कोई समस्या है?
• किसी दिए गए स्मृति स्थान पर एक प्रक्रिया लागू करना?
  • उस मेमोरी लोकेशन में क्या है?
  • यदि वस्तु मौजूद नहीं है, या बुरी स्थिति में है तो क्या होगा?
• कांजी युक्त एक स्ट्रिंग पर एक रेगेक्स का उपयोग कर?
  • Regex मॉड्यूल यूनिकोड को संभाल सकता है?
  • Regex यूनिकोड को संभाल सकता है?

Comments

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

— जोएरी सेब्रचेट्स

@JoeriSebrechts ठीक है, मैं काटूँगा: क्यों एक डेटाबेस में एक असंगत तर्क में nontrivial तर्क है, और इसे एक अलग-बनाए हुए कार्यक्रम में रखने की तुलना में इसे एक एंटीपैटर्न से अधिक क्या है?

— ब्लर एफएल

@ दो कारण, DB में तर्क तक पहुँचने के लिए एपीआई एक वेब सेवा एपीआई (संस्करण के लिए कठिन, कठिन का उपयोग करने के लिए, आसानी से कैश्ड नहीं है ...) से नीच है, और डेटाबेस इसे साफ-सुथरी संरचना और बनाए रखने के लिए कठिन बनाते हैं। कोडबेस ने उनके अंदर मेजबानी की। मेरे अनुभव में डेटाबेस के सामने किसी वेब सेवा में उस डेटाबेस के मुकाबले तर्क को होस्ट करना आसान है।

— जोएरी सेब्रेट्स

@JoeriSebrechts मैं यह सुनिश्चित करता हूं कि अधिकांश डेटाबेस प्लेटफ़ॉर्म विश्वसनीय, उपयोगी और विकसित करने योग्य API को लागू करने के लिए शक्तिशाली उपकरण प्रदान करते हैं। कई मायनों में यह निश्चित रूप से बहुत दर्द महसूस करने का निमंत्रण है। मेरा कहना था कि यह परिप्रेक्ष्य के बारे में है, यह महसूस करते हुए कि डीबी एक फैंसी फ़ाइल है, या यह वास्तव में एक अलग सेवा है अगला सवाल है कि कैसे लपेटें कि उपयोग की उस शैली का समर्थन करें। मैं उस पर स्पष्ट होने के लिए अपने उत्तर को विस्तृत करूँगा।

— Kain0_0

Answer 3

नहीं, आपको सत्यापन करने के लिए ट्रिगर का उपयोग कभी नहीं करना चाहिए।

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

डेटाबेस अखंडता के लिए सत्यापन के तीन स्तरों का प्रदर्शन करते हैं। पहले एक क्षेत्र स्तर सत्यापन है। एक फ़ील्ड की आवश्यकता हो सकती है, अगर कोई मूल्य नहीं है (अशक्त) यह एक त्रुटि है। यह एक चेक बाधा भी हो सकता है; एक डोमेन में मूल्यों की संख्या होती है।

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

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

मान्यता आवेदन की चिंता है। तथ्य यह है कि एक जर्मन डाक कोड में केवल अंक होते हैं, यह एक ऐसा चेक होता है, जिसे एप्लिकेशन को बनाना चाहिए, डेटाबेस से नहीं। लाइन एक पतली है, इसलिए आपको कुछ मामलों में कुछ सोच / चर्चा की आवश्यकता हो सकती है यदि कुछ ट्रिगर (आपके डेटाबेस की अखंडता की रक्षा) या एप्लिकेशन (सत्यापन का सामना कर रहे उपयोगकर्ता) में होना चाहिए।

Comments

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

— बोरबज

@Borjab: डेटाबेस को सही रखने के रूप में मान्यता, हो सकता है। लेकिन उपयोगकर्ता सत्यापन का सामना करना पड़ रहा है? संख्या

— मेंनो होल्सचर

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

— डॉक ब्राउन

@DocBrown अंतर डेटाबेस को भ्रष्टाचार और सत्यापन का सामना करने वाले उपयोगकर्ता से बचाने के बीच है। इसलिए "किसी और मान्यता" में मैं सत्यापन का सामना करने वाले उपयोगकर्ता को संदर्भित करता हूं। मैं इस भेद को और अधिक स्पष्ट कैसे कर सकता था? एक शुरुआत के रूप में मैंने "आगे" हटा दिया।

— मेंनो होल्सचर

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

— क्वर्टी

Answer 4

ऑडिट प्रभावी रूप से ट्रिगर्स के उपयोग का एक उत्कृष्ट उदाहरण है। मुझे परीक्षक द्वारा की गई कुछ त्रुटियां मिली हैं (एक ग्राहक को सेवा के एक स्तर से दूसरे स्तर पर ले जाना) एक ऑडिट टेबल के लिए धन्यवाद जो ट्रिगर के साथ लागू किया गया था। मैं ऑडिट के लिए ट्रिगर्स का उपयोग करने की अत्यधिक सलाह देता हूं।

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

Answer 5

क्योंकि सवाल यह है कि अगर हमें वास्तव में रिलेशनल डेटाबेस के लिए ट्रिगर्स की आवश्यकता है तो यहां कुछ अन्य उपयोग के मामले हैं जहां ट्रिगर्स का उपयोग करना है:

1. अन्य उत्तरों में वर्णित ऑडिटिंग के लिए।
2. व्यापक अर्थों में ऑडिटिंग: यदि एक डेटाबेस प्रविष्टि को बदल दिया जाता है, तो ट्रिगर असंगत पोस्ट प्रोसेसिंग के लिए घटना को रिकॉर्ड कर सकता है, जैसे रात में किसी अन्य एप्लिकेशन को निर्यात करता है।
3. विचारों के लिए ट्रिगर: ट्रिगर को परिभाषित किया जा सकता है instead of। इस अर्थ के साथ, एक दृश्य से प्रविष्टियां सम्मिलित, अद्यतन और हटा सकते हैं। ट्रिगर इन क्रियाओं को कई तालिकाओं पर फैला सकते हैं। यह अंतर्निहित तालिकाओं के विवरण को उजागर किए बिना प्रतिबंधित दृश्य उपलब्ध कराने का एक तरीका है।
4. स्पष्ट रूप से डेटाबेस को बचाने के लिए चारों ओर मुड़ें: एक मान लें: तालिका ए और बी और एक मध्यवर्ती तालिका आर के बीच एम संबंध। आप आर से ए तक विदेशी प्रमुख बाधाओं को परिभाषित कर सकते हैं और साथ ही बी यह भी निर्दिष्ट कर सकते हैं कि आर में प्रवेश को गिराया जाना है यदि इसकी B में संबंधित प्रविष्टि हटा दी गई है। हालाँकि, व्यापार तर्क को कभी-कभी आवश्यकता होती है कि A में प्रविष्टियों का कम से कम B में प्रविष्टि से कोई संबंध होना चाहिए। इस स्थिति में R को हटाने पर ट्रिगर इस तर्क को लागू करने में मदद कर सकता है: यदि A में प्रविष्टि के लिए R में अंतिम प्रविष्टि है नष्ट कर दिया जाता है तो ट्रिगर ए को हटा सकता है। अनुप्रयोग केंद्रित दृश्य में कम से कम दो टर्न अराउंड आवश्यक हैं। यह मान्यता के लिए एक उदाहरण है। अन्य उदाहरण बोधगम्य हैं: उपयोग के मामलों के बगल में (1), (2),
5. विश्वास: कभी-कभी डेटाबेस व्यवस्थापक आपके आवेदन का उपयोग नहीं करते हुए कमांड लाइन पर प्रविष्टियां बदलते हैं। एडमिन ध्यान से काम करते हैं और जानते हैं कि वे क्या करते हैं। हालांकि, कभी-कभी वे गलत भी हो सकते हैं। यदि स्थिरता महत्वपूर्ण है तो ट्रिगर उनकी सुरक्षा बेल्ट है।

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