database रबन क्या डेटाबेस कुंजी में विदेशी कुंजी वास्तव में आवश्यक हैं?




संबंधपरक डेटाबेस प्रबंधन प्रणाली (19)

जहां तक ​​मुझे पता है, प्रोग्रामर को सही तरीके से डेटा में हेरफेर करने में सहायता करने के लिए विदेशी कुंजी (एफके) का उपयोग किया जाता है। मान लीजिए कि एक प्रोग्रामर वास्तव में इसे सही तरीके से कर रहा है, तो क्या हमें वास्तव में विदेशी कुंजी की अवधारणा की आवश्यकता है?

क्या विदेशी कुंजी के लिए कोई अन्य उपयोग है? क्या मुझसे कोई चूक हो रही है?


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


परियोजनाओं (व्यवसाय अनुप्रयोगों और सोशल नेटवर्किंग वेबसाइटों) में घोषित विदेशी कुंजी कभी स्पष्ट नहीं थी (मुख्य कुंजी संदर्भ तालिका (कॉलम)) जिस पर मैंने काम किया था।

लेकिन हमेशा नामकरण कॉलम का एक तरह का सम्मेलन था जो विदेशी कुंजी थी।

यह डेटाबेस सामान्यीकरण के समान है - आपको पता होना चाहिए कि आप क्या कर रहे हैं और इसके परिणाम क्या हैं (मुख्य रूप से प्रदर्शन)।

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

इसके अलावा विभिन्न डेटाबेस इंजन अलग-अलग तरीकों से विदेशी कुंजी की सेवा कर सकते हैं, जो प्रवासन के दौरान सूक्ष्म बग का कारण बन सकता है।

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


हाँ।

  1. वे आपको ईमानदार रखते हैं
  2. वे नए डेवलपर्स ईमानदार रखते हैं
  3. आप ON DELETE CASCADE कर सकते हैं
  4. वे आपको अच्छे आरेख उत्पन्न करने में मदद करते हैं जो स्वयं तालिकाओं के बीच संबंधों को समझाते हैं

एक विदेशी कुंजी के बिना आप कैसे कहते हैं कि विभिन्न तालिकाओं में दो रिकॉर्ड संबंधित हैं?

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


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

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

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

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


हम वर्तमान में विदेशी कुंजी का उपयोग नहीं करते हैं। और अधिकांश भाग के लिए हमें खेद नहीं है।

उस ने कहा - हम कई कारणों से निकट भविष्य में उन्हें बहुत अधिक उपयोग करने की संभावना है, दोनों ही इसी कारण से:

  1. आरेखण। विदेशी कुंजी रिश्ते सही तरीके से उपयोग किए जाने पर डेटाबेस के आरेख का उत्पादन करना इतना आसान है।

  2. उपकरण समर्थन। विजुअल स्टूडियो 2008 का उपयोग करके डेटा मॉडल बनाने के लिए बहुत आसान है जिसका उपयोग LINQ to SQL लिए किया जा सकता है यदि उचित विदेशी कुंजी संबंध हैं।

तो मुझे लगता है कि मेरा मुद्दा यह है कि हमने पाया है कि यदि हम बहुत सारे मैन्युअल SQL कार्य कर रहे हैं (क्वेरी, क्वेरी क्वेरी, blahblahblah) विदेशी कुंजी जरूरी नहीं है। एक बार जब आप औजारों का उपयोग करना शुरू कर देते हैं, तो वे बहुत अधिक उपयोगी हो जाते हैं।


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


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

कोड में, हम आम तौर पर कहीं भी एक अपवाद फेंक देंगे - लेकिन SQL , हम आम तौर पर केवल "गलत" उत्तरों प्राप्त करेंगे।

सिद्धांत रूप में, SQL Server एक क्वेरी प्लान के हिस्से के रूप में बाधाओं का उपयोग कर सकता है - लेकिन विभाजन के लिए चेक बाधाओं को छोड़कर, मैं यह नहीं कह सकता कि मैंने वास्तव में कभी देखा है।


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

मान लीजिए कि एक प्रोग्रामर वास्तव में इसे सही तरीके से कर रहा है, तो क्या हमें वास्तव में विदेशी कुंजी की अवधारणा की आवश्यकता है?

सैद्धांतिक रूप से, नहीं। हालांकि, बग के बिना सॉफ्टवेयर का एक टुकड़ा कभी नहीं रहा है।

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

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

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

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

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


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


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

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

मुझे लगता है कि यह विकास की गति में व्यापार के लायक है। निश्चित रूप से, आप उनके साथ त्वरित कोड कर सकते हैं और शायद यही कारण है कि कुछ लोग उनका उपयोग नहीं करते हैं। व्यक्तिगत रूप से मैंने NHibernate और कुछ विदेशी कुंजी बाधाओं के साथ कई घंटों की हत्या कर दी है जो कुछ ऑपरेशन करते समय क्रोधित हो जाते हैं। हालांकि, मुझे पता है कि समस्या क्या है इसलिए यह एक समस्या से कम है। मैं सामान्य उपकरण का उपयोग कर रहा हूं और इस तरह के काम करने में मदद करने के लिए संसाधन हैं, संभवतः यहां तक ​​कि लोगों की मदद करने के लिए!

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


मान लीजिए कि एक प्रोग्रामर वास्तव में इसे सही तरीके से कर रहा है

ऐसा लगता है कि इस तरह की एक प्रकृति मुझे बेहद बुरा विचार मानती है; सामान्य सॉफ्टवेयर में असाधारण रूप से छोटी गाड़ी है।

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

यद्यपि एक आदर्श दुनिया में, प्राकृतिक जुड़ने वाले कॉलम नामों के बजाय संबंधों (यानी एफके बाधाओं) का उपयोग करेंगे। यह एफके को और भी उपयोगी बना देगा।


एफके बाधाओं के बिना एक डेटाबेस स्कीमा सीट बेल्ट के बिना ड्राइविंग की तरह है।

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

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

आपको क्यों लगता है कि यह आधुनिक भाषाओं के भीतर भी कठिन और अस्वीकार्य बना दिया गया है?



हाँ। ऑन डिलीट [रिस्ट्रिक्ट | कैस्केड] डेटा को साफ रखने के लिए डेवलपर्स को डेटा को फेंकने से रोकता है। मैंने हाल ही में रेल डेवलपर्स की एक टीम में शामिल हो गए जिन्होंने विदेशी कुंजी जैसे डाटाबेस बाधाओं पर ध्यान केंद्रित नहीं किया।

सौभाग्य से, मैंने ये पाया: http://www.redhillonrails.org/foreign_key_associations.html - रेल प्लग-इन पर रूबी पर रेडहिल कॉन्फ़िगरेशन शैली पर सम्मेलन का उपयोग करके विदेशी कुंजी उत्पन्न करता है। Product_id के साथ माइग्रेशन उत्पाद तालिका में आईडी के लिए एक विदेशी कुंजी बनाएगा।

लेन-देन में लिपटे माइग्रेशन समेत RedHill में अन्य महान प्लग-इन देखें।


आप विदेशी कुंजी को एक बाधा के रूप में देख सकते हैं कि,

  • डेटा अखंडता बनाए रखने में मदद करें
  • दिखाएं कि डेटा एक दूसरे से कैसे संबंधित है (जो व्यवसाय तर्क और नियमों को लागू करने में मदद कर सकता है)
  • यदि सही तरीके से उपयोग किया जाता है, तो तालिका से डेटा प्राप्त करने के साथ दक्षता में वृद्धि करने में मदद मिल सकती है।

मुझे लगता है कि कुछ बिंदुओं पर कुछ चीजें मान्य रिश्तों को सुनिश्चित करने के लिए जिम्मेदार होनी चाहिए।

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

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

उस समय, विदेशी कुंजी वास्तव में निरंतर हैं, क्योंकि वे आपको जिम्मेदारी को एक बिंदु पर फिर से स्थानांतरित करने की अनुमति देते हैं।


जहां तक ​​मुझे पता है, प्रोग्रामर को सही तरीके से डेटा में हेरफेर करने के लिए विदेशी कुंजी का उपयोग किया जाता है।

एफके डीबीए को उपयोगकर्ताओं की झुकाव से डेटा अखंडता की रक्षा करने की अनुमति देता है जब प्रोग्रामर ऐसा करने में विफल रहता है, और कभी-कभी प्रोग्रामर के झुकाव के खिलाफ सुरक्षा के लिए।

मान लीजिए कि एक प्रोग्रामर वास्तव में इसे सही तरीके से कर रहा है, तो क्या हमें वास्तव में विदेशी कुंजी की अवधारणा की आवश्यकता है?

प्रोग्रामर प्राणघातक और गिरने योग्य हैं। एफके घोषणात्मक हैं जो उन्हें खराब करने में कठोर बनाता है।

क्या विदेशी कुंजी के लिए कोई अन्य उपयोग है? क्या मुझसे कोई चूक हो रही है?

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


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

सब कुछ ठीक हो सकता है, लेकिन सोचें कि क्या होगा जब आपका प्रोग्रामर छोड़ देता है और किसी और को लेना पड़ता है।

विदेशी कुंजी उन्हें कोड की हजारों लाइनों के माध्यम से बिना किसी समस्या के डेटाबेस संरचना को समझने की अनुमति देगी।





foreign-keys