डेटाबेस पर प्रतिबंध लगाने में संकोच न करें। आपके पास एक सुसंगत डेटाबेस होना सुनिश्चित होगा, और यह डेटाबेस का उपयोग करने के अच्छे कारणों में से एक है। विशेष रूप से यदि आपके पास इसके लिए अनुरोध करने वाले कई एप्लिकेशन हैं (या केवल एक एप्लिकेशन लेकिन प्रत्यक्ष मोड और विभिन्न स्रोतों का उपयोग करके बैच मोड के साथ)।
MySQL के साथ आपके पास पोस्टग्रेएसक्यूएल की तरह उन्नत बाधाएं नहीं हैं लेकिन कम से कम विदेशी कुंजी बाधाएं काफी उन्नत हैं।
हम एक उदाहरण लेंगे, एक कंपनी तालिका जिसमें उपयोगकर्ता तालिका होगी जिसमें थीसिस कंपनी के लोग शामिल होंगे
CREATE TABLE COMPANY (
company_id INT NOT NULL,
company_name VARCHAR(50),
PRIMARY KEY (company_id)
) ENGINE=INNODB;
CREATE TABLE USER (
user_id INT,
user_name VARCHAR(50),
company_id INT,
INDEX company_id_idx (company_id),
FOREIGN KEY (company_id) REFERENCES COMPANY (company_id) ON...
) ENGINE=INNODB;
आइए देखें अद्यतन पर खंड:
- अद्यतन प्रतिबंध पर :डिफ़ॉल्ट :यदि आप तालिका कंपनी में company_id को अपडेट करने का प्रयास करते हैं, तो इंजन ऑपरेशन को अस्वीकार कर देगा यदि एक उपयोगकर्ता कम से कम इस कंपनी से लिंक करता है।
- अपडेट पर कोई कार्रवाई नहीं :RESTRICT के समान।
- अपडेट कैस्केड पर :आमतौर पर सबसे अच्छा :यदि आप कंपनी_आईडी को तालिका की एक पंक्ति में अपडेट करते हैं, तो इंजन इस कंपनी को संदर्भित करने वाली सभी उपयोगकर्ता पंक्तियों के अनुसार इसे अपडेट करेगा (लेकिन उपयोगकर्ता तालिका, चेतावनी पर कोई ट्रिगर सक्रिय नहीं है)। इंजन आपके लिए परिवर्तनों को ट्रैक करेगा, यह अच्छा है।
- अद्यतन सेट पर शून्य :यदि आप कंपनी_आईडी को तालिका की एक पंक्ति में अपडेट करते हैं, तो इंजन संबंधित USERs company_id को NULL (USER company_id फ़ील्ड में उपलब्ध होना चाहिए) पर सेट कर देगा। मुझे अपडेट में इससे जुड़ी कोई दिलचस्प बात नहीं दिख रही है, लेकिन मैं गलत हो सकता हूं।
और अब हटाएं पर . पर पक्ष:
- हटाएं प्रतिबंध पर :डिफ़ॉल्ट :यदि आप तालिका में कंपनी_आईडी आईडी को हटाने का प्रयास करते हैं, तो इंजन ऑपरेशन को अस्वीकार कर देगा यदि एक उपयोगकर्ता कम से कम इस कंपनी से लिंक करता है, तो आपका जीवन बचा सकता है।
- कोई कार्रवाई नहीं हटाएं :RESTRICT के समान
- डिलीट कैस्केड पर :खतरनाक :यदि आप तालिका कंपनी में कंपनी पंक्ति को हटाते हैं तो इंजन संबंधित USER को भी हटा देगा। यह खतरनाक है लेकिन सेकेंडरी टेबल पर ऑटोमैटिक क्लीनअप करने के लिए इस्तेमाल किया जा सकता है (इसलिए यह कुछ ऐसा हो सकता है जो आप चाहते हैं, लेकिन निश्चित रूप से कंपनी के लिए नहीं<->USER उदाहरण)
- डिलीट सेट न्यूल पर :मुट्ठी भर :यदि आप किसी कंपनी पंक्ति को हटाते हैं तो संबंधित उपयोगकर्ता स्वतः ही NULL से संबंध स्थापित कर लेंगे। यदि बिना कंपनी वाले उपयोगकर्ताओं के लिए नल आपका मूल्य है, तो यह एक अच्छा व्यवहार हो सकता है, उदाहरण के लिए हो सकता है कि आपको कुछ सामग्री के लेखक के रूप में उपयोगकर्ताओं को अपने एप्लिकेशन में रखने की आवश्यकता हो, लेकिन कंपनी को हटाना आपके लिए कोई समस्या नहीं है।
आमतौर पर मेरा डिफ़ॉल्ट है:अपडेट कैस्केड पर DELETE RESTRICT पर . कुछ के साथ ON DELETE CASCADE ट्रैक टेबल के लिए (लॉग--सभी लॉग नहीं--, ऐसी चीजें) और ON DELETE SET NULL जब मास्टर टेबल विदेशी कुंजी वाली तालिका के लिए एक 'सरल विशेषता' है, जैसे USER तालिका के लिए JOB तालिका।
संपादित करें
मुझे लिखे हुए काफी समय हो गया है। अब मुझे लगता है कि मुझे एक महत्वपूर्ण चेतावनी जोड़नी चाहिए। MySQL में कैस्केड के साथ एक बड़ी प्रलेखित सीमा है। कैस्केड ट्रिगर सक्रिय नहीं कर रहे हैं . इसलिए यदि आप उस इंजन में ट्रिगर्स का उपयोग करने के लिए पर्याप्त रूप से आश्वस्त थे, तो आपको कैस्केड बाधाओं से बचना चाहिए।
==> नीचे देखें अंतिम संपादन, इस डोमेन पर चीजें चल रही हैं
और मुझे नहीं लगता कि यह एक दिन ठीक हो जाएगा। विदेशी कुंजी बाधाओं को InnoDb स्टोरेज द्वारा प्रबंधित किया जाता है और ट्रिगर्स को MySQL SQL इंजन द्वारा प्रबंधित किया जाता है। दोनों अलग हो गए हैं। बाधा प्रबंधन के साथ इनोडब एकमात्र भंडारण है, हो सकता है कि वे एक दिन सीधे भंडारण इंजन में ट्रिगर जोड़ दें, शायद नहीं।
लेकिन मेरी अपनी राय है कि खराब ट्रिगर कार्यान्वयन और बहुत उपयोगी विदेशी कुंजी बाधाओं के समर्थन के बीच आपको कौन सा तत्व चुनना चाहिए। और एक बार जब आप डेटाबेस स्थिरता के अभ्यस्त हो जाएंगे तो आप PostgreSQL को पसंद करेंगे।
12/2017-MySQL के बारे में इस संपादन को अपडेट करना:
जैसा कि @IstiaqueAhmed ने टिप्पणियों में कहा है, इस विषय पर स्थिति बदल गई है। तो लिंक का अनुसरण करें और वास्तविक अप-टू-डेट स्थिति की जांच करें (जो भविष्य में फिर से बदल सकती है)।
