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


94

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

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

+66

"मान लीजिए कि एक प्रोग्रामर वास्तव में इसे सही तरीके से कर रहा है" - मैं इस तरह के परिदृश्य की कल्पना भी नहीं कर सकता। 19 apr. 092009-04-19 15:05:38

+11

"विदेशी कुंजी" एक विचार है, एक तकनीक नहीं। यह एक संबंधपरक नियम है। आपका प्रश्न वास्तव में इस बारे में है कि आपको अपने कोड में नियम लागू करने का प्रयास करना चाहिए या डेटाबेस को आपकी सहायता करने दें। जब समेकन शामिल होता है, तो डेटाबेस इंजन को नियम लागू करने देना सर्वोत्तम होता है, क्योंकि यह डेटाबेस में होने वाली हर चीज से अवगत है, जबकि आपका कोड संभवतः अवगत नहीं हो सकता है। 25 aug. 092009-08-25 18:20:01

  0

@Triynko, विदेशी कुंजी की अवधारणा संबंधपरक नियम नहीं है। 08 feb. 102010-02-08 12:21:33

  0

@Triynko - जो कहा गया है उस पर विस्तार करने के लिए, विदेशी कुंजी एक संबंधपरक नियम नहीं हैं, वे एक * रिलेशनशिप * नियम 12 feb. 102010-02-12 21:30:26

+5

@ लुब्स और cdeszaq हैं। असल में, यह एक संबंधपरक नियम है ... यह कोडड की "ट्विलेव कमांडमेंट्स" ... "ईमानदारी स्वतंत्रता" के नियम 10 का सबसेट है, जो मूल रूप से कहता है कि आरडीबीएमएस की रिलेशनल अखंडता को किसी भी एप्लिकेशन से स्वतंत्र रूप से बनाए रखा जाना चाहिए, जो इसे एक्सेस करता है, जो एक बिल्कुल समझने योग्य तरीके से मैं समझा रहा था। यह नियम अन्य चीजों के साथ, विदेशी कुंजी बाधाओं के द्वारा लागू किया गया है। तो हाँ, एक विदेशी कुंजी का विचार "ए" संबंधपरक नियम है। 24 feb. 102010-02-24 22:01:31

  0

@Triynko, यह मेरे ऊपर है कि मैं दो संबंधों के बीच संदर्भित अखंडता चाहता हूं या नहीं। कहीं भी लिखा नहीं गया है कि अगर मेरे पास ग्राहक और चालान हैं, तो मुझे उनके बीच रेफरेंसियल अखंडता भी रखना चाहिए और बनाए रखना चाहिए। मुझे लगता है कि हम दोनों सहमत हैं कि लागू होने पर रेफरेंसियल अखंडता को लागू करना एक अच्छा विचार है, लेकिन यह एक अच्छा विचार है, संबंधपरक मॉडल की आवश्यकता नहीं है। 25 feb. 102010-02-25 12:46:27

+1

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

  0

एक विदेशी कुंजी रिमोट प्राथमिक कुंजी की तरह है।जब आपके पास दो संबंधित तालिकाओं हों, तो एक विदेशी कुंजी डेटा को एक अलग तालिका से लिंक करती है, जो अन्यथा मूल तालिका में (अनावश्यक रूप से) शामिल की जाएगी। संबंधपरक मॉडल संबंधित तालिकाओं में डेटा को अलग करके अनावश्यकता को खत्म करने में कार्य करता है, इसलिए विदेशी कुंजी संबंधपरक मॉडल के लिए मौलिक हैं। आईएमओ, यदि कोई संबंध मौजूद है, तो इसे लागू किया जाना चाहिए। यदि आप इस तरह के संबंध को लागू नहीं करना चुनते हैं, तो आपका डेटाबेस आईएमओ बेकार है :), घटनाओं का एक पूरा रिकॉर्ड बनाए रखता है, और अंततः शून्य अनुप्रयोगों के साथ आपके आवेदन को अपंग कर सकता है। 01 mar. 102010-03-01 18:38:56

  0

@Triynko, अगर आप संबंध का मतलब है तो कृपया संबंध न कहें। यह भ्रमित है क्योंकि संबंधपरक मॉडल में, संबंध tuples का एक सेट है जो एक ही प्रकार का साझा करता है, रिश्ते नहीं। जब आप अनावश्यकता को खत्म करने के बारे में बात करते हैं, तो आप रिलेशनल मॉडल के बारे में बात नहीं कर रहे हैं, आप डेटाबेस सामान्यीकरण या 3 एनएफ के बारे में बात कर रहे हैं। संबंध मॉडल को 1 एनएफ में परिभाषित नियमों के न्यूनतम सेट का पालन करना होगा। रेफरेंसियल अखंडता, विदेशी कुंजी, रिडंडेंसी उन्मूलन 1 एनएफ के नियम नहीं हैं इसलिए वे संबंधपरक मॉडल की आवश्यकताओं को पूरा करने के नियम नहीं हैं। उम्मीद है कि अब यह समझ में आता है। 02 mar. 102010-03-02 01:26:08

  0

@lubos: एक रिश्ते और एक रिश्ता एक ही बात है। आपको यह समझने की आवश्यकता है कि एक रिश्ते दो विवादास्पद संबंधों (तालिकाओं) को एक तार्किक संबंध में बाधित करता है। दूसरे शब्दों में, एक रिश्ते में दो संबंध शामिल होते हैं, जो उचित रूप से बाधित होने पर तर्कसंगत रूप से एक संबंध के बराबर होते हैं। जब आप जॉइन क्वेरी लिखते हैं, तो परिणाम एक सिंगल रिलेशन (टेबल) होता है। आप जो कह रहे हैं वह है कि 'रिलेशनल मॉडल' मूल स्प्रेडशीट का वर्णन करता है, और मैं पूरी तरह से असहमत हूं। 02 mar. 102010-03-02 22:56:28

  0

विकिपीडिया से "रिलेशनल मॉडल": "डेटा का * रिलेशनल मॉडल * डेटाबेस डिजाइनर को सूचना का एक सतत, तार्किक प्रतिनिधित्व बनाने की अनुमति देता है। डेटाबेस डिज़ाइन में * घोषित बाधाओं * सहित समेकन प्राप्त किया जाता है, जिसे आमतौर पर संदर्भित किया जाता है * लॉजिकल स्कीमा *। सिद्धांत * डेटाबेस सामान्यीकरण की प्रक्रिया शामिल है * जिससे कुछ वांछित गुणों के साथ एक डिज़ाइन * तर्कसंगत समकक्ष विकल्पों * के सेट से चुना जा सकता है। " 02 mar. 102010-03-02 22:57:07

  0

... जारी रखा: "एक रिलेशनल डेटाबेस की स्थिरता लागू होती है, जो अनुप्रयोगों में निर्मित नियमों द्वारा नहीं, बल्कि तार्किक स्कीमा के हिस्से के रूप में घोषित बाधाओं और सभी अनुप्रयोगों के लिए डीबीएमएस द्वारा लागू की जाती है। सामान्य रूप से , बाधाओं को रिलेशनल तुलना ऑपरेटर का उपयोग करके व्यक्त किया जाता है, जिनमें से केवल एक "उप-समूह" (⊆) है, सैद्धांतिक रूप से पर्याप्त है। व्यावहारिक रूप से, कई उपयोगी शॉर्टेंड उपलब्ध होने की उम्मीद है, जिनमें से सबसे महत्वपूर्ण उम्मीदवार कुंजी (वास्तव में, सुपरकी) और विदेशी कुंजी बाधाएं। " 02 mar. 102010-03-02 22:58:09

  0

मुझे निम्नलिखित में से "जो आप कह रहे हैं ..." को दोबारा दोहराएं (क्योंकि संपादन अक्षम हो रहा है): "आप जो कह रहे हैं वह है .. 'रिलेशनल मॉडल' को बनाए रखने से संबंधित विचारों को शामिल नहीं करता है सामान्यीकरण उद्देश्यों के लिए शारीरिक रूप से विघटन होने पर संबंध की अखंडता, लेकिन मुझे लगता है कि इसमें यह शामिल है। " 02 mar. 102010-03-02 23:09:48

  0

ध्यान दें कि कोडड के "नियम" को आरडीबीएमएस द्वारा समर्थित रेफरेंसियल अखंडता बाधाओं की आवश्यकता नहीं है। नियम 10 बस निर्दिष्ट करता है कि अखंडता बाधाओं को स्वतंत्र रूप से लागू किया जाना चाहिए - यह नहीं कहता कि उन्हें किस तरह की बाधाएं होनी चाहिए। किसी भी मामले में, "नियम" संबंधपरक मॉडल की परिभाषा नहीं बनते थे और कभी नहीं थे। यह स्पष्ट है कि एक डेटाबेस में एक भी आरआई बाधा के बिना रिलेशनल हो सकता है और आरडीबीएमएस आरआई का भी समर्थन नहीं कर सकता है (यह सिर्फ इतना है कि शायद इसमें बहुत से इच्छुक ग्राहक नहीं होंगे)। 31 mar. 112011-03-31 15:19:07

+2

यह अक्सर यहां के आसपास आता है। मैं दोषी [जोएल स्पॉस्की] (http://en.wikipedia.org/wiki/Joel_Spolsky) :-)। यहां कई अच्छे उत्तर हैं; मेरा पुनः टाइप करने के बजाय, मैं आपको सिर्फ एक लिंक दूंगा: http://stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys 19 apr. 092009-04-19 15:02:54

95

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

+45

यदि आपको एक इंडेक्स बनाने की आवश्यकता है, तो यह प्राथमिक नहीं होना चाहिए एफके के लिए कारण। (वास्तव में कुछ परिस्थितियों में (उदाहरण के लिए चयन से अधिक आवेषण) एफके को बनाए रखना धीमा हो सकता है।) 21 mar. 102010-03-21 17:28:57

+3

यह एक भयानक उत्तर है एफके जीनेरली अतिरिक्त प्रदर्शन को बेहतर बनाने के लिए अतिरिक्त ओवरहेड जोड़ सकते हैं। 13 feb. 152015-02-13 18:42:34

  0

SQL-सर्वर में, वे डिफ़ॉल्ट रूप से रेफरी या रेफरर पर अनुक्रमित नहीं होते हैं। http://www.sqlskills.com/blogs/kimberly/when-did-sql-server-stop-putting-indexes-on-foreign-key-columns/ 27 jun. 162016-06-27 20:26:43

  0

न ही ओरेकल में; आपको खुद को इंडेक्स (एफके कॉलम पर) बनाना होगा। 10 feb. 182018-02-10 20:17:01


55

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

+7

हालांकि यह शायद व्यापार तर्क परत में संभाला जाना चाहिए। यह तय करना कि संबंधित बाल अभिलेख रखना है या नहीं, यह सुनिश्चित करने के समान नहीं है कि कोई मूल्य विदेशी कुंजी संबंधों का उल्लंघन नहीं करता है। 06 oct. 082008-10-06 21:38:42

+4

अन्य मुद्दा ऑडिटिंग है, यदि ऑडिटिंग डीबी स्तर पर नहीं की जाती है, तो कैस्केडिंग अपडेट या डिलीट आपके ऑडिट ट्रेल को अमान्य कर देंगे। 01 sep. 092009-09-01 04:52:11

  0

@ कोडवेयर: व्यापार तर्क डीबी में हो सकता है। 01 feb. 112011-02-01 19:31:41

+2

@ ग्रेग हेगिल यह संभावित रूप से कई समस्याओं का कारण बन सकता है। आपको डिलीट कैस्केड जैसे विचारों से बहुत सावधान रहना चाहिए, क्योंकि कई मामलों में, आप उपयोगकर्ता को हटाते समय उपयोगकर्ता द्वारा बनाए गए ऑर्डर रखना चाहते हैं। 20 aug. 082008-08-20 20:28:12


41

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

वे आवश्यक नहीं हैं, सख्ती से बोल रहे हैं, लेकिन लाभ बहुत बड़े हैं।

मुझे काफी यकीन है कि FogBugz डेटाबेस में विदेशी कुंजी बाधा नहीं है। मुझे यह जानने में दिलचस्पी होगी कि कैसे Fog Creek Software टीम उनके कोड को गारंटी देने के लिए संरचना करती है, इससे पहले कि वे कभी भी असंगतता नहीं पेश करेंगे।

+39

जोएल: "अब तक हमें कोई समस्या नहीं है।" अभी तक, मैंने कभी दीपक पोस्ट में नहीं चलाया है। लेकिन मुझे अभी भी लगता है कि सीट बेल्ट पहनना अच्छा विचार है ;-) 04 nov. 082008-11-04 10:36:18

+2

हो सकता है कि आपने कभी समस्या नहीं देखी हो, लेकिन हो सकता है कि यह डेटाबेस हो ... अधिकांश डेटाबेस id_xxx जैसे एक सम्मेलन का उपयोग करते हैं जो बिल्कुल ठीक है ixXXX 05 feb. 092009-02-05 21:54:59

+1

@ जोएल: नियमों के प्रवर्तन के स्थान पर नामकरण सम्मेलन? जब आप इसमें हों तो साथ ही साथ टाइप कर सकते हैं। 17 sep. 092009-09-17 20:54:16

+8

@Eric: आप यहां फॉग क्रीक को सॉफ्टवेयर विकास के कुछ प्रकार के अवतार के रूप में पकड़ रहे हैं। यदि आपने कहा "न्यूयॉर्क शहर में एक कंपनी के पास उनके डीबी में विदेशी कुंजी नहीं है ..." हम सभी कहते हैं "और?" 17 sep. 092009-09-17 20:56:08

+1

@ जेकॉलम, मैंने स्टैक ओवरफ्लो के बीटा के दौरान उस टिप्पणी को बनाया, जब यहां सब लोग जानते थे कि जेफ और जोएल कौन थे, और शायद पॉडकास्ट को सुन रहे थे, इसलिए फोग क्रीक हर किसी के रडार पर था। 18 sep. 092009-09-18 12:04:23

  0

@ जेकॉलम: कुछ कहेंगे "और?" जबकि अन्य लोग "डब्ल्यूटीएफ" कहेंगे? (मैंने अभी किया), लेकिन मुझे लगता है कि एक दांत त्वचा के लिए एक से अधिक तरीके हैं। वैसे, "अवतार" का अच्छा उपयोग। :) 01 may. 102010-05-01 00:17:29

+3

एरिक: फोगबगज़ विदेशी कुंजी के लिए एक नामकरण सम्मेलन का उपयोग करता है। उदाहरण के लिए ixBug तालिका बग की प्राथमिक कुंजी में एक सूचकांक समझा जाता है। अब तक हमें कोई समस्या नहीं है। - जोएल स्पॉस्की 13 feb. 122012-02-13 01:48:13

  0

"अब तक हमें कोई समस्या नहीं है।" - सुधार: आपको कभी भी कोई समस्या नहीं है जिसे आप जानते हैं - जो आपके उपकरण को आपकी सहायता करने का एक और बड़ा कारण है। 24 feb. 132013-02-24 23:47:50

  0

एरिक के वास्तविक प्रश्न का जवाब देने के लिए, मेरी समझ यह है कि फॉग क्रीक सॉफ़्टवेयर को फॉग क्रीक द्वारा नियंत्रित सर्वरों पर होस्ट किया जाता है, न कि जंगली में संकुचित सॉफ़्टवेयर नहीं। इसका मतलब है कि वे * यह सुनिश्चित कर सकते हैं कि उनका डेटाबेस केवल उनके एप्लिकेशन सॉफ़्टवेयर के माध्यम से छेड़छाड़ की जा सके। इस संदर्भ में मैं अनुमान लगाता हूं कि एक ऑब्जेक्ट मॉडल है जो बाधाओं को लागू करता है। 11 jun. 132013-06-11 01:28:33


8

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

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


1

आप एक बाधा है कि,

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

6

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

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

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

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

+2

यह प्याज की तरह है। एफके रक्षा की आखिरी परत हैं। जब तक यह एक एम्बेडेड स्थानीय डेटाबेस नहीं है, तब तक रेफरेंसियल अखंडता करने की कोशिश करने वाले ऐप्स हमेशा एक बुरा विचार है। 04 oct. 132013-10-04 19:23:08


12

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

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

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

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

+2

अच्छा बिंदु, "ऑन [रिलेशनशिप]" या कुछ अन्य कीवर्ड के साथ दो तालिकाओं में शामिल होना अच्छा होगा और डीबी को यह पता लगाने दें कि कौन से कॉलम शामिल हैं। वास्तव में बहुत उचित लगता है। 17 sep. 092009-09-17 20:58:04


12

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

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

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

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

+2

+1 जब भी संभव हो चाबियाँ निरंतर रहती हैं। 30 jul. 092009-07-30 16:04:07


20

हां।

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

ईमानदारी से आपका क्या मतलब है? 06 sep. 152015-09-06 02:33:19

  0

मुझे लगता है कि धारणा के साथ ईमानदार। यह आपको त्वरित और लंगड़ा प्रोग्रामिंग करके डेटा के साथ धोखा देने से रोकता है। 08 jan. 172017-01-08 21:09:09


1

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

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

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

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

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

+1

मैं उन सिस्टम पर काम करता हूं जो उनका उपयोग नहीं करते हैं। और मुझे नियमित रूप से खेद है। मैंने और उदाहरण देखा है कि मैं गैर-संवेदी डेटा की गिनती कर सकता हूं जो उचित बाधाओं से रोका जा सकता था। 19 apr. 092009-04-19 15:15:25

  0

और लगभग छह महीने तक हमारी वर्तमान परियोजना पर विदेशी कुंजी के साथ काम कर रहे हैं, मैं पूरी तरह से इस टिप्पणी से सहमत हूं। 20 apr. 092009-04-20 13:17:03


4

वे सख्ती से जरूरी नहीं हैं, जिस तरह से सीटबेल सख्ती से जरूरी नहीं हैं। लेकिन वे वास्तव में आपको कुछ बेवकूफ करने से बचा सकते हैं जो आपके डेटाबेस को गड़बड़ कर देता है।

यह आपके आवेदन को तोड़ने वाले डिलीट को पुनर्निर्माण करने की तुलना में एक एफके बाधा त्रुटि को डीबग करने के लिए बहुत अच्छा है।


1

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

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

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

  0

विशिष्टता बाधाएं उच्च कार्डिनिटी का संकेत देती हैं जिसका उपयोग ऑप्टिमाइज़र द्वारा जुड़ने के तंत्र में चयन करने के लिए किया जाता है। Encapsulation और FK/PK रिश्तों के बीच एक अच्छा सादृश्य के लिए 22 dec. 092009-12-22 22:14:03


36

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

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

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

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

+2

+1। 17 sep. 092009-09-17 20:58:44


3

मुझे लागत/लाभ के मामले में इसके बारे में लगता है ... MySQL में, एक बाधा जोड़ना DDL की एक अतिरिक्त पंक्ति है। यह केवल कुछ मुट्ठी भर शब्दों और विचारों के कुछ सेकंड है। मेरी राय में यह केवल "लागत" है ...

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

जब आप चीजों को एक साथ रख रहे हों तो पहले से ही आपके सिर में जो कुछ भी हो रहा है उसे कोडित करने में थोड़ा सा समय आपको या किसी और को सड़क के नीचे दुःख महीनों या वर्षों का गुच्छा बचा सकता है।

प्रश्न:

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

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


1

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

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

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

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

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

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


8

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


0

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

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

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

  0

लिंक टूटा हुआ है। 10 aug. 132013-08-10 19:38:47


5

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

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

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


8

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

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

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

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

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

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

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

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


4

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


5

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

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

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

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

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

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

  0

यह एक अच्छा जवाब है। 23 mar. 132013-03-23 13:49:36


7

एफके बहुत महत्वपूर्ण हैं और हमेशा आपकी स्कीमा, unless you are eBay में मौजूद रहना चाहिए।

+1

अच्छा लिंक 01 dec. 092009-12-01 23:50:31

+2

कि लिंक वास्तव में बेहद आकर्षक है ... मैं वास्तव में अधिक जानकारी जानना चाहता हूं और अब मैं eBay का उपयोग करने के लिए कुछ हद तक डर रहा हूं। अन्य लोगों के लिए: चौथे प्रश्न पर क्लिक करें ताकि वह देख सकें कि वह अपनी डीबी संरचना के बारे में क्या कहता है। पूरा साक्षात्कार देखने लायक है, यद्यपि। भी ... 'unibrow' 23 aug. 132013-08-23 18:52:31


2

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

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

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

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