SQL सर्वर में कैस्केडिंग का उपयोग कब / क्यों करें?

149

SQL सर्वर में विदेशी कुंजी सेट करते समय, आपको किन परिस्थितियों में इसे डिलीट या अपडेट पर कैस्केड करना चाहिए, और इसके पीछे क्या कारण है?

यह संभवतः अन्य डेटाबेस पर भी लागू होता है।

मैं प्रत्येक परिदृश्य के ठोस उदाहरणों के लिए सबसे अधिक देख रहा हूं, अधिमानतः किसी ऐसे व्यक्ति से जिसने उन्हें सफलतापूर्वक उपयोग किया है।

— जोएल कोएहॉर्न
स्रोत

4

यह प्रश्न SQL सर्वर से सख्ती से संबंधित नहीं लगता है और सैद्धांतिक, सामान्य प्रश्न की तरह दिखता है। यदि आप sql-serverटैग हटाते हैं तो यह समुदाय के लिए अधिक उपयोगी होगा ।

— clapas

4

@clapas ईमानदारी से, अगर मैं आज यह पूछना चाहता था तो यह विषय से हटकर होगा। यदि उच्च विचारों / मतों के लिए यह इंगित नहीं करता है कि इसका मूल्य उस समुदाय से है जिसे मैं अभी हटाऊंगा।

— जोएल कोएहॉर्न

6

@JoelCoehoorn - स्पष्ट रूप से इन प्रकार के प्रश्नों का मूल्य है। यह मान समय बीतने के कारण नहीं फैलता है। मेरे मन में सवाल यह है कि आज इस तरह के सवालों को दरकिनार कर हम कितना मूल्य खो रहे हैं?

— पी। ब्रायन। मैके

2

@ P.Brian.Mackey यहाँ, यहाँ! कुछ सबसे अच्छे प्रश्न / उत्तर जो मैंने देखे हैं, वे नीचे दिए गए विषय के रूप में वोट दिए गए हैं या चित्रित किए गए हैं ... लेकिन आप बड़े वोटों की बड़ी मात्रा के द्वारा बता सकते हैं कि कई का सटीक प्रश्न था!

— एंथनी ग्रिग्स

कैस्केडिंग क्रियाएं क्रमिक ताले लेती हैं।

— मिच गेहूं

126

मैंने अब तक जो देखा है उसका सारांश:

कुछ लोगों को कैस्केडिंग बिल्कुल पसंद नहीं है।

कैस्केड डिलीट

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

कैस्केड अपडेट

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

कैस्केडिंग का उपयोग कब करें

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

— जोएल कोएहॉर्न
स्रोत

3

ध्यान दें कि कैस्केड अपडेट भी अक्सर उपयोग किए जाते हैं जहां "तथाकथित" प्राकृतिक कुंजियां दिखाई देती हैं ये वास्तविक प्रभावी अद्वितीय कुंजी नहीं हैं। वास्तव में मुझे विश्वास है कि कैस्केड अपडेट केवल खराब सामान्यीकृत डेटाबेस मॉडल के साथ की जरूरत है, और वे गंदे तालिकाओं और गंदे कोड के लिए एक खुला गेट हैं।

— फिलिप ग्रोनडियर

1

आप एक महत्वपूर्ण बिंदु को याद कर रहे हैं, यदि बच्चे के कई रिकॉर्ड हैं, तो कैस्केडिंग विशाल प्रदर्शन के मुद्दे बना सकता है।

— एचएलजीईएम

13

@HLGEM - मुझे प्रासंगिकता नहीं दिख रही है। यदि कैस्केड संचालन धीमा हो जाता है, तो समान मैन्युअल प्रक्रिया या तो उसी धीमी गति का कारण बनेगी या लेन-देन को पीछे ले जाने की स्थिति में सही तरीके से संरक्षित नहीं होगी।

— जोएल कोएहॉर्न

3

यह क्यों फर्क पड़ेगा कि क्या एक IDENTITY या ऑटो-इन्क्रीमेंट कॉलम पर कैस्केड अपडेट है? मैं देख सकता हूं कि यह आवश्यक क्यों नहीं होगा क्योंकि आपको उन (मनमाने) मूल्यों को बदलने की आवश्यकता नहीं होनी चाहिए, लेकिन यदि उनमें से एक ने बदलाव किया, तो कम से कम संदर्भात्मक अखंडता बरकरार रहेगी।

— केनी एविट

3

10 गोलियां? खैर अब हम जानते हैं कि जोएल रिवॉल्वर से फायरिंग नहीं कर रहा है।

— नील एन

68

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

जो चीज खराब है, वह विदेशी चाबियों का गलत उपयोग है, जैसे उन्हें पीछे की ओर बनाना, उदाहरण के लिए।

जुआन मैनुअल का उदाहरण कैनोनिकल उदाहरण है, यदि आप कोड का उपयोग करते हैं, तो डेटाबेस में स्प्रिटियस डॉक्यूमेंटइम्स छोड़ने के कई और अधिक मौके हैं जो आपको आकर काट लेंगे।

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

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

— विन्को वर्सलोविक
स्रोत

7

'प्राकृतिक' प्राथमिक कुंजी के उस प्रकार का उपयोग करना पहली जगह में वास्तव में खराब विचार है।

— निक जॉनसन

4

आरईएन को निर्देशित की गई टिप्पणी। नहीं, FK पर CASCADE को छोड़ने से नकली डेटा छोड़ने की संभावना नहीं बढ़ती है। यह इस संभावना को कम कर देता है कि एक आदेश से अधिक डेटा प्रभावित होगा और कोड में वृद्धि होगी। FK को छोड़कर पूरी तरह से संयमी डेटा का एक मौका छोड़ देते हैं।

— शैनन सेवरेंस

5

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

— क्रूचन

1

मेरे पास वास्तव में कोडित सिस्टम है जहां एक प्रबंधन निर्णय लिया गया है कि उपयोगकर्ताओं को मास्टर-डिटेल में स्पष्ट रूप से सभी बच्चों को हटाने से पहले उन्हें मास्टर को हटाने के लिए बस उपयोगकर्ता को सोचने के लिए मजबूर कर सकता है। जब तार्किक रूप से फायरब्रेक का एक समान प्रकार हो सकता है तो कैस्केड का उपयोग नहीं करना।

— क्रूचन

6

@ कुरुचन: नियम, मेरे विचार से, सरल है। यदि डेटा मूल माता-पिता के डेटा के बिना बेकार के रूप में दृढ़ता से संबंधित नहीं है, तो यह कैस्केड संबंध का वारंट नहीं करता है। यह मैंने अपने उत्तर पर अंतिम वाक्यांश में संबोधित करने की कोशिश की।

— विंको वर्सालोविच

17

मैं कभी भी कैस्केडिंग डिलीट का उपयोग नहीं करता।

अगर मुझे डेटाबेस से कुछ हटाया जाए तो मैं स्पष्ट रूप से डेटाबेस को बताना चाहता हूं कि मैं क्या लेना चाहता हूं।

बेशक वे डेटाबेस में उपलब्ध एक फ़ंक्शन हैं और ऐसे समय हो सकते हैं जब उनका उपयोग करना ठीक है, उदाहरण के लिए यदि आपके पास एक 'ऑर्डर' टेबल और एक 'ऑर्डर' टेबल है, तो आप आइटम हटा सकते हैं जब आप एक हटा सकते हैं गण।

मुझे स्पष्टता पसंद है कि मैं इसे 'जादू' होने के बजाय कोड (या संग्रहीत प्रक्रिया) में करने से प्राप्त करता हूं।

उसी कारण से मैं ट्रिगर्स का प्रशंसक नहीं हूं।

ध्यान देने वाली बात यह है कि यदि आप एक 'ऑर्डर' को हटाते हैं, तो आपको '1 पंक्ति प्रभावित' रिपोर्ट वापस मिल जाएगी, भले ही कैस्केड डिलीट ने 50 'ऑर्डरटाइट को हटा दिया हो।

— Loofer
स्रोत

34

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

— मुसिएनेसिस

4

@MusiGenesis, Aidan FK को हटाने की वकालत नहीं कर रहा था। FK अभी भी डेटा की सुरक्षा करता है, लेकिन CASCADE ON के बिना .... अनपेक्षित जादू नहीं होता है।

— शैनन सेवरेंस

7

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

— शान्नोन सीवियर

3

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

— क्रूचन

5

@ विन्को: 'गैसप' एसपी क्यों? एसपी रक्षात्मक रूप से जाने का रास्ता है जहां डेटाबेस एक महत्वपूर्ण कॉर्पोरेट संपत्ति है। परिस्थितियों के प्रकार में एक मजबूत तर्क है कि सभी डेटा एक्सेस को एसपी तक सीमित करने के बारे में बात कर रहे थे , या कम से कम सभी का चयन करें। मेरे जवाब को stackoverflow.com/questions/1171769/… के

— क्रूचन

13

मैं कैस्केडिंग डिलीट के साथ बहुत काम करता हूं।

यह जानना अच्छा लगता है कि जो भी डेटाबेस के खिलाफ काम करता है वह कभी भी कोई अवांछित डेटा नहीं छोड़ सकता है। अगर निर्भरता बढ़ती है तो मैं प्रबंधन स्टूडियो में आरेख में बाधाओं को बदल देता हूं और मुझे सपा या डेटाकेस को मोड़ना नहीं है।

उस ने कहा, मुझे कैस्केडिंग डिलीट और दैट सर्कुलर रेफरेंस के साथ 1 समस्या है। यह अक्सर डेटाबेस के उन हिस्सों की ओर जाता है जिनमें कोई कैस्केडिंग डिलीट नहीं होती है।

— मैथियास एफ
स्रोत

1

मुझे पता है कि यह बहुत पुराना है, लेकिन CASCADE DELETE के साथ परिपत्र संदर्भ मुद्दे का उल्लेख करने के लिए +1।

— कोड मेवरिक

2

क्षमा एक दोपहर का प्रश्न: यदि आप एक परिपत्र संदर्भ प्राप्त करते हैं तो वास्तव में क्या होता है?

— टिम लोवेल-स्मिथ

10

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

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

सामान्य तौर पर मैं पूरी तरह से वास्तविक डिलीट से बचता हूं और तार्किक डिलीट का उपयोग करता हूं (यानी एक बिट कॉलम होता है जिसे डिलीट किया जाता है जो इसके बजाय सेट हो जाता है)।

— Martynnw
स्रोत

2

आपने मुझे कुछ और जानने के लिए उत्सुक किया। आप तार्किक रूप से हटाए गए लोगों को क्यों पसंद करते हैं? क्या जिस डेटा के साथ आप काम कर रहे हैं, उसका इससे कोई लेना-देना नहीं है?

— टिम लोवेल-स्मिथ

9

एक उदाहरण तब है जब आपके पास संस्थाओं के बीच निर्भरता है ... अर्थात: दस्तावेज़ -> डॉक्यूमेंटइमेट्स (जब आप डॉक्यूमेंट को हटाते हैं, तो डॉक्यूमेंट इटम्स का कोई कारण नहीं होता)

— Juan
स्रोत

5

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

मुझे लगता है कि यह सुनिश्चित करने के लिए कैस्केड डिलीट उपयोगी है कि अशक्त अपवादों के बजाय मृत संदर्भों को डिफ़ॉल्ट रूप से हटा दिया जाए।

— परीक्षण पैटर्न
स्रोत

5

कैस्केड हटाएं:

जब आप चाहते हैं कि चाइल्ड टेबल में पंक्तियों को हटा दिया जाए यदि इसी पंक्ति को हटा दिया जाए पेरेंट टेबल में ।

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

अपडेट कैस्केड पर:

जब आप विदेशी कुंजी में अपडेट की जाने वाली प्राथमिक कुंजी में परिवर्तन चाहते हैं

— दुराई अमुथन। एच
स्रोत

5

मैंने डीबीए और / या "कंपनी नीति" के बारे में सुना है जो अतीत में खराब अनुभवों के कारण "ऑन डिलीट कैस्केड" (और अन्य) को शुद्ध रूप से उपयोग करने से रोकते हैं। एक मामले में एक लड़के ने तीन ट्रिगर लिखे जो एक दूसरे को कॉल करने के लिए समाप्त हो गए। ठीक होने में तीन दिन लगे क्योंकि ट्रिगर्स पर कुल प्रतिबंध, सभी एक ईदजीत के कार्यों के कारण।

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

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

क्या यह सब विकास नहीं है?

— BrianBurkill
स्रोत

मुझे नहीं लगता था कि यह सब कुछ हटा देगा ... आपका मतलब है कि वास्तव में यह वही करता है जो यह कहता है? ...

— जोएल कोएहॉर्न

3

कैस्केड डिलीट में डालने का एक कारण (कोड में इसे करने के बजाय) प्रदर्शन में सुधार करना है।

केस 1: कैस्केड डिलीट के साथ

 DELETE FROM table WHERE SomeDate < 7 years ago;

केस 2: कैस्केड डिलीट किए बिना

 FOR EACH R IN (SELECT FROM table WHERE SomeDate < 7 years ago) LOOP
   DELETE FROM ChildTable WHERE tableId = R.tableId;
   DELETE FROM table WHERE tableId = R.tableid;
   /* More child tables here */
 NEXT

दूसरे, जब आप कैस्केड डिलीट के साथ एक अतिरिक्त चाइल्ड टेबल में जोड़ते हैं, तो केस 1 में कोड काम करता रहता है।

मैं केवल एक कैस्केड में रखूंगा जहां संबंध का शब्दार्थ "भाग" है। अन्यथा कुछ बेवकूफ आपके डेटाबेस का आधा हिस्सा तब हटा देगा जब आप ऐसा करेंगे:

DELETE FROM CURRENCY WHERE CurrencyCode = 'USD'

— WW।
स्रोत

5

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

— HLGEM

2

मैं डिलीट या अपडेट से बचने की कोशिश करता हूं जो मैंने SQL सर्वर में स्पष्ट रूप से अनुरोध नहीं किया था।

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

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

— pauliephonic
स्रोत

2

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

एकमात्र मामला जहां मैं उपयोग करूंगा, यदि तालिका तालिका में डेटा अत्यधिक नियंत्रित है (उदाहरण के लिए, सीमित अनुमतियाँ) और केवल एक नियंत्रित प्रक्रिया (जैसे सॉफ्टवेयर अपडेट) के माध्यम से सत्यापित या हटा दिया गया है जिसे सत्यापित किया गया है।

— जेन ए
स्रोत

1

एक विलोपन या अपडेट जो S के कुछ tuples में पाया गया एक विदेशी-कुंजी मान को हटाता है, को तीन में से एक में संभाला जा सकता है:

अस्वीकार
प्रचार
अकृतीकरण।

प्रसार को कैस्केडिंग कहा जाता है।

दो मामले हैं:

‣ यदि एस में एक ट्यूपल को हटा दिया गया था, तो उस आर ट्यूपल को हटा दें जो इसे संदर्भित करता है।

‣ यदि S में एक ट्यूपल अपडेट किया गया था, तो उस आर ट्यूपल में मान को अपडेट करें जो इसे संदर्भित करता है।

— मयंक चोपड़ा
स्रोत

0

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

मैंने अभी कुछ समय के लिए कैस्केड हटाने को हतोत्साहित करने के बाद दो पहले से मौजूद तालिकाओं (केवल हटाने के लिए चौराहे) के बीच एक नए चौराहे की मेज के लिए कैस्केड हटा दिया। यदि डेटा खो जाता है तो यह बहुत बुरा नहीं है।

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

एक अन्य समस्या यह है कि जब प्राथमिक कुंजी हटा दी गई है तब भी मूल विदेशी कुंजी मान रखे जाएंगे। कोई मूल FK के लिए एक tombstone कॉलम और ON DELETE SET NULL विकल्प बना सकता है, लेकिन इसके लिए फिर से ट्रिगर या विशिष्ट कोड की आवश्यकता होती है ताकि निरर्थक (PK विलोपन के बाद) कुंजी मान को बनाए रखा जा सके।

— एरिक हार्ट
स्रोत

0

एक भौतिक डेटाबेस में तार्किक सुपर-प्रकार और उप-प्रकार की संस्थाओं को लागू करते समय कैस्केड डिलीट बेहद उपयोगी होते हैं।

जब अलग-अलग सुपर-प्रकार और उप-प्रकार टेबल का उपयोग सुपर-प्रकार / उप-प्रकारों को भौतिक रूप से लागू करने के लिए किया जाता है (जैसा कि सभी उप-प्रकार की विशेषताओं को एक ही भौतिक सुपर-प्रकार तालिका में रोल करने के लिए विरोध किया जाता है), एक-एक होता है -इन तालिकाओं और समस्या के बीच संबंध तब बनता है कि इन तालिकाओं के बीच प्राथमिक कुंजी को 100% कैसे रखा जाए।

कैस्केड डिलीट एक बहुत ही उपयोगी टूल हो सकता है:

1) सुनिश्चित करें कि सुपर-प्रकार के रिकॉर्ड को हटाने से संबंधित एकल उप-प्रकार के रिकॉर्ड को भी हटा दिया जाता है।

2) सुनिश्चित करें कि सब-टाइप रिकॉर्ड को हटाने से सुपर-टाइप रिकॉर्ड भी नष्ट हो जाता है। यह उप-प्रकार तालिका पर "ट्रिगर-ऑफ" डिलीट ट्रिगर को लागू करके प्राप्त किया जाता है जो संबंधित सुपर-प्रकार के रिकॉर्ड को हटाता है और हटाता है, जो बदले में, कैस्केड उप-प्रकार रिकॉर्ड को हटा देता है।

इस तरीके से कैस्केड डिलीट का उपयोग करना सुनिश्चित करता है कि कोई भी अनाथ सुपर-टाइप या सब-टाइप रिकॉर्ड मौजूद नहीं है, भले ही आप सुपर-टाइप रिकॉर्ड को हटा दें या पहले सब-टाइप रिकॉर्ड को हटा दें।

— मार्क एलन
स्रोत

अच्छा उदाहरण। JPA में, यह InheritanceStrategy टेबल में शामिल हो गया है। 1) के लिए: आम तौर पर, आप एक दृढ़ता परत ढांचे (EclipseLink, Hibernate, ...) का उपयोग कर रहे हैं, जो पहले शामिल हुए हिस्से को हटाने के लिए एक सम्मिलित इकाई के लिए हटाए गए अनुक्रम को लागू करता है, फिर सुपर भाग। लेकिन अगर आपके पास आयात या संग्रह की नौकरी की तरह अधिक बुनियादी सॉफ़्टवेयर हैं, तो सुपर भाग पर एक डिलीट जारी करके केवल इकाई को हटाने में सक्षम होना सुविधाजनक है। 2 के बारे में): सहमत हैं, लेकिन उस मामले में ग्राहक को पहले से ही पता होना चाहिए कि वह इकाई के शामिल / उप भाग पर काम कर रहा है।

— leo