259

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

क्या लोगों के पास कुछ ठोस कारण हैं जैसे (स्टैक ओवरफ्लो सिद्धांतों के साथ चर्चा से बचने के लिए) क्यों?

संपादित करें: "मेरे पास अभी तक एक विदेशी कुंजी बनाने का एक कारण है, इसलिए यह वास्तव में एक सेट करने का मेरा पहला कारण हो सकता है।"

— ज़ोलोमन
स्रोत

9

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

— डैरन थॉमस

6

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

— टोनी एंड्रयूज

22

... आम तौर पर यह बाधा नहीं जोड़ने के लिए मूर्खता है: यह हर समय अखंडता को बनाए रखता है, भले ही आवेदन कोड में एक बग हो या यदि आपका डेटा "ठीक" करने वाले दृश्यों के पीछे काम कर रहा हो।

— टोनी एंड्रयूज

2

टोनी की टिप्पणी के लिए +1। वहाँ सुविधा और विदेशी कुंजी की तार्किक अवधारणा के बीच बहुत अधिक भ्रम है।

— जॉनफैक्स

4

@ डनमैन, आपको नहीं पता कि आपने वह धारणा कहां से हासिल की है जो मुझे लगता है। मैं वास्तव में ऊपर कहता हूं "आम तौर पर यह बाधा जोड़ना मूर्खतापूर्ण नहीं है: यह हर समय अखंडता को बनाए रखता है"

— टोनी एंड्रयूज

352

विदेशी कुंजी का उपयोग करने के कारण:

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

विदेशी कुंजियों का उपयोग न करने के कारण:

आप हर CRUD ऑपरेशन पर DB कार्य को अतिरिक्त बना रहे हैं क्योंकि इसमें FK संगति की जाँच करनी है। यदि आपके पास बहुत मंथन है तो यह बड़ी लागत हो सकती है
रिश्तों को लागू करने से, एफके एक आदेश निर्दिष्ट करता है जिसमें आपको चीजों को जोड़ना / हटाना होता है, जो डीबी द्वारा मना कर सकता है कि आप क्या चाहते हैं। (दी गई बात, ऐसे मामलों में, जो आप करने की कोशिश कर रहे हैं, वह एक अनाथ पंक्ति बना रहा है, और यह आमतौर पर अच्छी बात नहीं है)। जब आप बड़े बैच अपडेट कर रहे होते हैं, तो यह विशेष रूप से दर्दनाक होता है, और आप एक टेबल को दूसरे से पहले लोड करते हैं, दूसरी टेबल के साथ सुसंगत स्थिति बनाते हैं (लेकिन क्या आपको इस तरह का काम करना चाहिए अगर कोई संभावना है कि दूसरा लोड विफल हो और आपका डेटाबेस अब असंगत है?)।
कभी-कभी आपको पता होता है कि आपका डेटा गंदा होने वाला है, आप इसे स्वीकार करते हैं, और आप चाहते हैं कि DB इसे स्वीकार कर ले
आप आलसी हो रहे हैं :-)

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

— स्क्वायरकॉग
स्रोत

12

अच्छी सूची! DBMs CRUD के "R" भाग के लिए निरंतरता की जाँच नहीं करेंगे, इसलिए मैं उस हिस्से को बाहर निकालूँगा। इसके अलावा, यह संभवतः एक धोने है क्योंकि आपके ऐप में आप वही काम करते हैं जो डीबीएमएस करता है: आप यह सुनिश्चित करेंगे कि मूल आईडी सीआरडी से पहले मान्य है और यह वास्तव में धीमे होने की तुलना में डीबीएम है!

— मैट रोजिश

6

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

— मैट रोजिश

7

सटीक रूप से - यह डीबी का काम होना चाहिए, क्योंकि यह एकमात्र है जो कई समवर्ती ग्राहकों के चेहरे में लेनदेन की गारंटी दे सकता है।

— स्क्वायरकॉग

3

+1 उत्कृष्ट उत्तर - एफके बाधाओं का उपयोग न करने का दूसरा कारण "निरंतरता को तोड़ने के लिए कठिन बना देता है" के बारे में सोचा जा सकता है जो वास्तव में एक अच्छी बात लगती है!

— बिल कार्वेन

9

विदेशी कुंजी एफएआर का उपयोग करने के लाभ मेरी राय में उनका उपयोग न करने के किसी भी लाभ से आगे निकल जाते हैं।

— निक बेडफोर्ड

80

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

यदि, हालांकि, आपके पास RDBMS से संबंधित प्रयासों के साथ आपके अतीत में ऐसा गहन या सकारात्मक अनुभव नहीं है, तो संभवतः आपको ऐसी जानकारी से अवगत नहीं कराया गया है। या शायद आपके अतीत में एक ऐसे वातावरण में विसर्जन शामिल है जो मुखर रूप से एंटी-डेटाबेस था (उदाहरण के लिए, "वे डीबीए बेवकूफ हैं - हम कुछ, हमने कुछ जावा / सी # कोड स्लिंगर्स को दिन बचाएंगे") चुना, जिसमें आप का विरोध किया जा सकता है। कुछ dweeb के आर्कन बेबीलिंग्स आपको बता रहे हैं कि अगर आप सिर्फ सुनेंगे तो FK (और वे बाधा डाल सकते हैं) वास्तव में महत्वपूर्ण हैं।

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

— एड लुकास
स्रोत

61

मैं डिस्टिल्ड का उपयोग करने जा रहा हूं "विदेशी चाबियाँ आपके दांतों को ब्रश करने की तरह हैं: आगे बढ़ें, इसके बिना करें, लेकिन जब आप मुस्कुराते हैं तो सावधान रहें"

— मार्क सोउल

5

मुझे व्यक्तिगत रूप से पता चलता है कि RDBMS के सिद्धांत बहुत सरल हैं और मौखिक स्वच्छता की तुलना में बहुत अच्छी तरह से परिभाषित हैं

— अली गंगजी

भविष्य में 10 साल, मुझे यकीन है कि यह डेटाबेस डिजाइन मेरे बेटे / बेटी के साथ बात करने जा रहा है ताकि वह गड़बड़ न हो और एक डेटाबेस समस्या के कारण अगली दीवार सड़क दुर्घटना का कारण बन जाए।

— वरुणअगव

52

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

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

— AlexCuse
स्रोत

26

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

— एरिक 1

1

आमतौर पर ऐसा लगता है। मुझे लगता है कि आप केवल डेटाबेस में लागू करने के साथ दूर हो सकते हैं (जब तक कि आपके उपयोगकर्ता रनटाइम अपवादों को ध्यान में नहीं रखते हैं) लेकिन दोनों के पास जाने का एकमात्र तरीका है।

— एलेक्सक्यूज

ट्रांसक्रिप्शंस / एटवुड की प्रतिक्रिया में इसकी सभी "एटवुड: ... उन विदेशी कुंजियों के आधार पर जो आप अनुक्रमित में सेट करते हैं, वे इसे समझ लेते हैं ... स्पोलस्की: [हंसते हुए] यह मानते हुए कि आप ऐसा करते हैं। एटवुड: ठीक है, यह मानते हुए। आप अपने डेटाबेस को ठीक से सेट करें ... "

— मेमेडेवेलर

4

तालिकाओं के बीच संबंधों के कारण डेटाबेस को संबंधपरक नहीं कहा जाता है (हर तरह के डेटाबेस में संस्थाओं के बीच कुछ प्रकार के संबंध हैं!), लेकिन क्योंकि तालिकाएं स्वयं संबंध हैं , गणित की दृष्टि से। विकिपीडिया देखें ।

— मासिमिलियानो क्रूस

41

किसी भी संबंधपरक डेटाबेस मॉडल के लिए विदेशी कुंजी आवश्यक है।

— गैल्व
स्रोत

54

मॉडल, हाँ। कार्यान्वयन, आवश्यक नहीं, बस संभवतः उपयोगी है।

— dkretz

4

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

— प्रहरी

2

नहीं, विदेशी चाबियां "संबंधपरक" इंगित करने के लिए अनिवार्य नहीं हैं

— सिल्वर मून

यह वास्तव में ज्यादा नहीं समझाता है।

— ना

29

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

इस तथ्य में भी है कि कई प्रणालियों को आम तौर पर डेटाबेस के साथ सीधे इंटरफ़ेस करने की आवश्यकता होती है - अन्य प्रणालियों से जो डेटा को पढ़ते हैं (क्रिस्टल रिपोर्ट) उन सिस्टमों में जो डेटा सम्मिलित करते हैं (जरूरी नहीं कि एक एपीआई का उपयोग करके जो मैंने डिज़ाइन किया है; यह एक द्वारा लिखा जा सकता है; सुस्त-समझदार प्रबंधक जिन्होंने अभी-अभी VBScript की खोज की है और SQL बॉक्स के लिए SA पासवर्ड है)। अगर डेटाबेस उतना बेवकूफ नहीं है, जितना संभव हो सकता है, तो अलविदा डेटाबेस।

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

— चींटी
स्रोत

2

अच्छी अंतर्दृष्टि। मेरा तर्क है कि डेटा हर उस एप्लिकेशन के लिए महत्वपूर्ण है जो वास्तव में उपयोग किया जाता है। केवल एक चीज जो अलग है वह है भ्रष्ट डेटा के परिणाम। वे आपकी तरह के ऐप के लिए उच्च हैं ...

— Jay Godse

20

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

विदेशी कुंजी स्वचालित परीक्षण को जटिल बनाती है

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

हालाँकि, accountsएक विदेशी कुंजी है contracts, और contractsएक fk to है clients, और clientsएक fk to है cities, और citiesएक fk to है states।

अब डेटाबेस आपको चार टेबलों में डेटा सेट किए बिना अपना परीक्षण चलाने की अनुमति नहीं देगा जो आपके परीक्षण से संबंधित नहीं हैं ।

इस पर कम से कम दो संभावित दृष्टिकोण हैं:

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

परीक्षण चलाते समय विदेशी कुंजी जांच को अस्थायी रूप से बंद करना भी संभव हो सकता है। MySQL, कम से कम, यह समर्थन करता है ।

— रिवील किया
स्रोत

मुझे लगता है कि मैं आमतौर पर यहाँ मध्य मार्ग के लिए जा रहा हूँ: मैं FKs का उपयोग करता हूँ, फिर मैं यूनिट-टेस्ट हेल्पर विधियाँ लिखता हूँ जो विभिन्न परीक्षण परिदृश्यों का समर्थन करने के लिए DB की स्थापना करता है, उदाहरण के लिए किसी भी परीक्षण के लिए "शहरों" और "राज्यों" को बनाने के लिए एक सहायक विधि। उन तालिकाओं की जरूरत है।

— joelpt

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

— JeeBee

3

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

— a_horse_with_no_name

2

यदि आप किसी व्यावसायिक परत से अपडेट का परीक्षण कर रहे हैं, तो आपके विकास के वातावरण में FK मौजूद होना चाहिए। जब आप अपना रिकॉर्ड अपडेट करते हैं, तो आपके पास कॉलम वैल्यू होनी चाहिए जो आपको अपडेट के लिए जरूरी है। अन्यथा, IMHO आपका परीक्षण मान्य नहीं है।

— कीऑफजे

3

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

— एंड्रियास बर्गस्ट्रॉम

16

"वे रिकॉर्ड को अधिक बोझिल बना सकते हैं - आप" मास्टर "रिकॉर्ड को नहीं हटा सकते हैं जहां अन्य तालिकाओं में रिकॉर्ड हैं जहां विदेशी चाबियाँ उस बाधा का उल्लंघन करती हैं।"

यह याद रखना महत्वपूर्ण है कि SQL मानक उन क्रियाओं को परिभाषित करता है जो किसी विदेशी कुंजी को हटाने या अपडेट किए जाने पर ली जाती हैं। जिन्हें मैं जानता हूं वे हैं:

ON DELETE RESTRICT- किसी अन्य पंक्तियों को अन्य तालिका में रोकता है जिसमें इस कॉलम की कुंजियाँ हटा दी जा रही हैं। यह केन रे ने ऊपर वर्णित किया है।
ON DELETE CASCADE - यदि दूसरी तालिका की एक पंक्ति हटा दी जाती है, तो इस तालिका की किसी भी पंक्तियों को हटा दें जो इसे संदर्भित करती है।
ON DELETE SET DEFAULT - यदि दूसरी तालिका में एक पंक्ति हटा दी जाती है, तो कॉलम के डिफ़ॉल्ट पर संदर्भित किसी भी विदेशी कुंजी को सेट करें।
ON DELETE SET NULL - यदि दूसरी तालिका में एक पंक्ति हटा दी जाती है, तो किसी भी विदेशी कुंजी को इस तालिका में शून्य करने के लिए संदर्भित करें।
ON DELETE NO ACTION- यह विदेशी कुंजी केवल यह बताती है कि यह एक विदेशी कुंजी है; अर्थात् मैपर में उपयोग के लिए।

ये वही क्रियाएं भी लागू होती हैं ON UPDATE।

डिफॉल्ट किस पर निर्भर करता है एसक्यूएल सर्वर आप उपयोग कर रहे हैं।

— पॉवरलॉर्ड
स्रोत

14

@ शिष्टाचार - यह बिल्कुल उसी तरह की मानसिकता है जो रखरखाव बुरे सपने का कारण बनता है।

क्यों ओह आप घोषणात्मक संदर्भात्मक अखंडता की उपेक्षा क्यों करेंगे, जहां डेटा को कम से कम सुसंगत होने की गारंटी दी जा सकती है, तथाकथित "सॉफ्टवेयर प्रवर्तन" के पक्ष में जो सबसे अच्छा एक कमजोर निवारक उपाय है।

— एड Guiness
स्रोत

क्योंकि इसमें शामिल डेवलपर्स ने एक समस्या का सामना नहीं किया है जो गैर-तुच्छ, सामान्यीकृत, संबंधपरक मॉडल की मांग करता है। कई समस्याएँ नहीं हैं, विशेष रूप से वेब / "सोशल मीडिया" प्रकार की प्रोग्रामिंग जो कि आज सभी को पसंद आ रही है। यदि कोई ORM ढांचे के पिछले छोर को छोड़ देता है, तो अल्फा में समस्या को संतुष्ट करता है, किसी के लिए भी डेटा मॉडलिंग के बारे में अधिक सोचना संभव नहीं है। इस तरह की कई समस्याएं K / V स्टोर्स, डॉक्यूमेंट डेटाबेस या स्ट्रेट ऑब्जेक्ट सीरियललाइजेशन द्वारा आसानी से हैंडल की जाती हैं।

— zxq9

12

उन्हें उपयोग न करने का एक अच्छा कारण है: यदि आप उनकी भूमिका को नहीं समझते हैं या उनका उपयोग कैसे करते हैं।

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

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

— केंट फ्रेड्रिक
स्रोत

8

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

— ग्वेल्यूम

2

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

— बेंजामिन

^ यह। वे उपयोगी उपकरण हैं, लेकिन एक नौसिखिए के हाथों में, वे खतरनाक उपकरण हैं।

— कैंट फ्रेड्रिक

11

उनके उपयोग न करने के कोई अच्छे कारण नहीं हैं ... जब तक कि अनाथ पंक्तियाँ आपके लिए एक बड़ी बात नहीं हैं, मुझे लगता है।

— मैट रोजिश
स्रोत

11

अनाथ पंक्तियों को एक बड़ी बात क्यों कहा जाता है?

— ओसुवा सेप

2

मल्टीथ्रेडिंग के बारे में क्या? वे कुछ स्थितियों में एक बहु दुःस्वप्न पैदा कर सकते हैं। डेटाबेस लिखने वाले कई थ्रेड्स के साथ एक जटिल एप्लिकेशन में उन वस्तुओं का सामना करना पड़ सकता है जो एक दूसरे को संदर्भित करने की आवश्यकता होती है, व्यापार तर्क में संदर्भात्मक अखंडता को नियंत्रित करना बेहतर होता है --- खासकर अगर टेबल बाद में स्थिर होने जा रहे हैं।

— कीथ पिंसन

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

— 8

4

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

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

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

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

QUERY PERFORMANCE - यदि विदेशी कुंजियों पर तालिकाओं को जोड़ दिया जाता है, तो इस तथ्य से संज्ञान लें कि विदेशी कुंजी कॉलम INDEXED नहीं हैं (हालांकि संबंधित प्राथमिक कुंजी परिभाषा द्वारा अनुक्रमित है)। किसी भी कुंजी को अनुक्रमित करके, किसी भी कुंजी को अनुक्रमित करके, और अनुक्रमित तालिकाओं में शामिल होने से, उस पर विदेशी कुंजी बाधा के साथ गैर-अनुक्रमित कुंजी में शामिल होने से नहीं, बल्कि उस प्रदर्शन के लिए एक विदेशी कुंजी को अनुक्रमित करके।

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

— जसबीर एल
स्रोत

खैर, मुझे नहीं पता कि क्यों रिक्त स्थान के स्थान पर 3 डबल न्यूलाइन्स डालना और दो शब्दों को '67% जोनाथन लेफ़लर 'के रूप में बदलना है, लेकिन मुझे नहीं लगता कि मैंने इस पर इतना काम किया है। मुख्य पाठ में @jay (उपयोगकर्ता 183837) का योगदान था।

— जोनाथन लेफ़लर

मैंने सिर्फ यह मान लिया था कि अधिकांश अन्य साइटों की तरह यहाँ भी पैराग्राफ काम नहीं करेंगे। इसलिए, मैंने इसे सभी में से एक के रूप में रखा, प्रवाह परिवर्तन के लिए सिलवटों का उपयोग करके।

— जसबीर एल

3

विदेशी कुंजी का उपयोग करने का अतिरिक्त कारण: - डेटाबेस के अधिक से अधिक पुन: उपयोग की अनुमति देता है

अतिरिक्त कारण विदेशी कुंजी का उपयोग नहीं करना: - आप पुन: उपयोग को कम करके अपने उपकरण में एक ग्राहक को लॉक करने की कोशिश कर रहे हैं।

— सज्जन
स्रोत

3

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

एफके से बचने के लिए इसका बेहतर है लेकिन इसके जोखिम को प्रोग्रामर्स द्वारा नियंत्रित किया जाना है।

— Rachit
स्रोत

8

मुझे नहीं लगता कि बड़े बैंकों में विकास के तरीके सुनहरे मानक तय करते हैं।

— एड्रियन कोस्टर

3

"रिकॉर्ड जोड़ने से पहले, जांचें कि एक अन्य तालिका में एक संबंधित रिकॉर्ड मौजूद है" व्यापार तर्क है।

यहाँ कुछ कारण हैं जो आप डेटाबेस में नहीं चाहते हैं:

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

— टॉम बी
स्रोत

2

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

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

— सैंटियागो पल्लेदिनो
स्रोत

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

— जय गोडसे

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

— पीटर वॉन

2

क्लेरिफ़ डेटाबेस एक व्यावसायिक डेटाबेस का एक उदाहरण है जिसमें कोई प्राथमिक या विदेशी कुंजी नहीं है।

http://www.geekinterview.com/question_details/18869

मजेदार बात यह है कि तकनीकी दस्तावेज यह बताने के लिए बहुत लंबाई में जाते हैं कि टेबल कैसे संबंधित हैं, उन्हें जोड़ने के लिए कौन से कॉलम का उपयोग करना है आदि।

दूसरे शब्दों में, वे स्पष्ट घोषणाओं (DRI) के साथ तालिकाओं में शामिल हो सकते थे लेकिन उन्होंने नहीं चुना ।

नतीजतन, क्लेरिफाई डेटाबेस विसंगतियों से भरा हुआ है और यह कमज़ोर है।

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

और मुझे लगता है कि, संबंधपरक डेटाबेस में विदेशी प्रमुख बाधाओं के न होने का मुख्य लाभ है। यह विकसित करना आसान बनाता है, कम से कम जो कि शैतान-मे-केयर की दृष्टि से है।

— एड Guiness
स्रोत

असंगत डेटा को संभालने के लिए कोड एक असफल रेफ़रेंशियल अखंडता की जाँच करने के लिए कोड की तुलना में बहुत छोटा है।

— जय गोडसे

@ जय सहमत! मुझे नहीं लगता कि मैं इस दृष्टिकोण की वकालत कर रहा हूं।

— एड गुनेस

2

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

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

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

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

— tvCa
स्रोत

1

वे रिकॉर्ड को अधिक बोझिल बना सकते हैं - आप "मास्टर" रिकॉर्ड को नहीं हटा सकते हैं जहां अन्य तालिकाओं में रिकॉर्ड हैं जहां विदेशी चाबियाँ उस बाधा का उल्लंघन करती हैं। आप कैस्केडिंग को हटाने के लिए ट्रिगर का उपयोग कर सकते हैं।

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

मेरा मानना है कि अग्निमय कुंजियों के उपयोग से होने वाले फायदे किसी भी संभावित नुकसान की आशंका है।

— केन रे
स्रोत

5

मैं किसी भी तरह चीजों को शायद ही कभी डिलीट करता हूं। बस चिह्न में "दृश्यमान / सक्रिय" बिट है।

— दाना

+1 के लिए "मेरा मानना है कि अग्निमय कुंजियों के उपयोग से होने वाले फायदे किसी भी संभावित नुकसान की आशंका है"

— इयान बॉयड

2

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

— डैनमैन

ग्राहक का नाम बदलना बिल्कुल भी दर्द नहीं होगा यदि आपकी विदेशी कुंजी CustomerId (PK) पर सेट है। आदेश तालिका में। इसका एक ही तरीका होगा कि यदि ग्राहक नेम पर एफके सेट न किया जाए तो ऐसा कभी नहीं होगा। IMHO

— कीओफजे

1

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

— remonedo
स्रोत

6

डुप्लिकेट और असंगत डेटा को हटाने में कितना CPU समय व्यतीत होता है?

— एड गुनेस

हाँ, यह सच है। एक प्रणाली पर मैं काम करता हूं, हमें एक डेटाबेस में एक बार में 10 - 40 ग्राम डेटा डालना होता है और कुल समय में और बिना एफके प्रदर्शन दिखाई देता है।

— पॉल मेंडोज़ा

1

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

— आर्नो
स्रोत

9

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

— चाड

1

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

संपादित करें: मेरा अनुमान है कि वह विदेशी प्रमुख बाधाओं का जिक्र कर रहे थे , न कि अवधारणा के रूप में विदेशी कुंजी।

— रिवॉर्ड्स लॉर्ड्सकार्लेट
स्रोत

नहीं। वह वास्तविक चाबियाँ पसंद नहीं करता है!

— ljs

वह मुझे हैरान करता है विदेशी कुंजी बाधाओं को पसंद नहीं करने और विदेशी कुंजी पसंद नहीं करने के बीच एक बड़ा अंतर है। मुझे यकीन नहीं है कि आपके पास उनके बिना एक संबंधपरक डेटाबेस कैसे है।

— लॉर्ड्सकार्लेट सेप

जब मैंने उसे सुना तो मैं चौंक गया था। वह अनजाने में जीभ-गाल हो सकता है; शायद वह यहाँ पोस्ट करेगा और किसी चरण में स्पष्ट करेगा :-)

— ljs

1

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

— CodeRot
स्रोत

1

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

मुझे लगता है कि मेरी सभी परियोजनाओं में से 99% में मेरे पास डेटा की अखंडता को लागू करने के लिए एफके होगा, हालांकि, ऐसे दुर्लभ अवसर हैं जहां मेरे पास ग्राहक हैं जो जरूरी नहीं कि कितना बुरा है, अपने पुराने डेटा को बनाए रखें ...। लेकिन फिर मैं बहुत समय कोड लिखने में बिताता हूं जो केवल वैसे भी वैध डेटा प्राप्त करने के लिए जाता है, इसलिए यह व्यर्थ हो जाता है।

— मिचेल सेलर्स
स्रोत

1

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

—
स्रोत

1

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

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

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

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

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

— एरिक
स्रोत

1

मैं दिमित्री द्वारा जवाब गूंज - बहुत अच्छी तरह से डाल दिया।

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

मैं आमतौर पर अपने डेटा मार्ट स्कीमा में कुछ तालिकाओं पर इस रणनीति का उपयोग करता हूं, लेकिन मेरे एकीकृत स्टेजिंग स्कीमा में नहीं। मैं यह सुनिश्चित करता हूं कि जिन तालिकाओं को मैं पहले से ही लागू कर रहा हूं, उनमें से एक ही बाधा है या ETL रूटीन बाधा को लागू करता है।

— माइक मैक्लिस्टर
स्रोत

1

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

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

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

— ज़क
स्रोत

5

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

— टिम गॉटियर

1

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

लेकिन यहाँ एक और बहुत अच्छा वास्तविक जीवन कारण विदेशी कुंजियों का उपयोग नहीं करना है:

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

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

इससे विभिन्न समस्याएं हो सकती हैं:

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

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

आप पूछ सकते हैं: किसे अलग डेटाबेस सिस्टम की जरूरत है? ठीक है, हर कोई अपनी मशीन पर एक पूर्ण विकसित SQL- सर्वर नहीं खरीद सकता है या नहीं चाहता है। यह सॉफ्टवेयर है, जिसे बनाए रखने की जरूरत है। दूसरों ने पहले से ही किसी अन्य DB प्रणाली में समय और पैसा लगाया है। सर्वरलेस डेटाबेस केवल एक मशीन पर छोटे ग्राहकों के लिए बहुत अच्छा है।

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

— माइकल
स्रोत

0

मैंने हमेशा सोचा कि उनका उपयोग न करना आलसी था। मुझे सिखाया गया कि इसे हमेशा किया जाना चाहिए। लेकिन फिर, मैंने जोएल की चर्चा नहीं सुनी। उसके पास एक अच्छा कारण हो सकता है, मुझे नहीं पता।

— Kilhoffer
स्रोत

यह एक चर्चा की तुलना में एक ऑफ-द-कफ टिप्पणी से अधिक था, हालांकि शायद मुझे सटीक रूप से शोध करना चाहिए कि वह स्वतंत्र रूप से इस विषय पर क्या सोचता है! हालाँकि मैं इस विषय पर समुदाय की राय के बारे में भी उत्सुक था!

— ljs

0

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

— hamishmcn
स्रोत

अगर मुझे समझ में आया कि आप क्या कहना चाह रहे हैं, तो मुझे लगता है कि मेरा जवाब लुकअप टेबल में रिकॉर्ड को डिलीट करने के लिए होगा या अब प्रासंगिक ऐतिहासिक डेटा को संग्रहीत नहीं करेगा और लुकअप रिकॉर्ड को भी संग्रहित करेगा।

— चाड

विदेशी कुंजियों में क्या गलत है?

विदेशी कुंजी स्वचालित परीक्षण को जटिल बनाती है