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

Question

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

इस तरह, आप निश्चित रूप से उन क्षेत्रों द्वारा दो तालिकाओं में शामिल हो सकते हैं जो अप्रत्याशित परिणाम होने पर विदेशी कुंजी होने के लिए नहीं हैं।

आपको ऐसा क्यों लगता है? डीबीएमएस को लागू नहीं करना चाहिए कि जुड़वां और उत्पाद केवल विदेशी कुंजी द्वारा किए जाएंगे?

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

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

Answer 1

विदेशी कुंजी बाधाओं का कारण यह है कि संदर्भित पंक्तियां मौजूद हैं।

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

इस प्रकार, संदर्भ तालिका में एक पंक्ति में वे मान नहीं हो सकते हैं जो संदर्भित तालिका (संभावित रूप से न्यूल को छोड़कर) में मौजूद नहीं हैं। इस तरह संदर्भों को एक साथ लिंक करने के लिए संदर्भ दिए जा सकते हैं और यह एक अनिवार्य हिस्सा है डेटाबेस सामान्यीकरण।"(Wikipedia)

---

उत्तर: आपका प्रश्न:" मैं फ़ील्ड FKS नहीं हैं द्वारा तालिकाओं में शामिल होने की जरूरत है कल्पना नहीं कर सकते ":

जब एक विदेशी कुंजी बाधा को परिभाषित करने, संदर्भित तालिका में कॉलम (रों), कम से कम एक उम्मीदवार कुंजी संदर्भित तालिका के प्राथमिक कुंजी होना चाहिए, या।

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

टी

CREATE TABLE clients (
    client_id  uniqueidentifier NOT NULL, 
    client_name  nvarchar(250)  NOT NULL, 
    client_country char(2)   NOT NULL 
); 

CREATE TABLE suppliers (
    supplier_id  uniqueidentifier NOT NULL, 
    supplier_name  nvarchar(250)  NOT NULL, 
    supplier_country char(2)   NOT NULL 
); 

और फिर इस प्रकार क्वेरी: वह निम्नलिखित एक उदाहरण है कि कोई मतलब सकता है

SELECT 
    client_name, supplier_name, client_country 
FROM 
    clients 
INNER JOIN 
    suppliers ON (clients.client_country = suppliers.supplier_country) 
ORDER BY 
    client_country; 

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

SELECT 
    state, electorate 
FROM 
    electorates 
INNER JOIN 
    postcodes on (postcodes.Location.STIntersects(electorates.Location) = 1); 

स्रोत: ConceptDev - SQL Server 2008 Geography: STIntersects, STArea

आप पोस्ट "Sql 2008 query problem - which LatLong’s exists in a geography polygon?" करने के लिए स्वीकार किए जाते हैं जवाब में एक और इसी तरह भू-स्थानिक उदाहरण देख सकते हैं:

SELECT 
    G.Name, COUNT(CL.Id) 
FROM 
    GeoShapes G 
INNER JOIN 
    CrimeLocations CL ON G.ShapeFile.STIntersects(CL.LatLong) = 1 
GROUP BY 
    G.Name; 

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

Answer 2

नहीं, प्रवर्तन अनावश्यक है; यह कॉलम के संभावित अधिभार जैसे कुछ उपयोगी कार्यक्षमता को अस्वीकार कर देगा। हालांकि इस तरह के उपयोग आदर्श नहीं है, यह कुछ वास्तविक दुनिया स्थितियों में उपयोगी है।

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

यह ध्यान दिया जाना चाहिए कि किसी दिए गए स्कीमा पर विदेशी कुंजी बाधाओं की एक महत्वपूर्ण कमी एक खराब "गंध" है, और कुछ गंभीर डिजाइन समस्याओं का संकेत दे सकती है।

Answer 3

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

Answer 4

डीबीएमएस का निर्माण अभी भी उनके मूल नियमों के अनुसार समाधान की व्यापक संख्या को अनुमति देने के लिए किया गया है।

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

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

Answer 5

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

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

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

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

Answer 6

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

तो क्यों कई परियोजनाएं विदेशी कुंजी को परिभाषित करती हैं?

• डाटा मॉडल खराब तरीके से तैयार और आवश्यकता है टूटा संदर्भ (उदाहरण:: बहुरूपी संघों, EAV) इसके कई कारण हैं।

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

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

  ;

Answer 7

क्योंकि व्यवहार में

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

हो सकता है आप कुछ समाधान है कि एक पूरी तरह से सामान्यीकृत तरह से (उदाहरण के लिए) में संग्रहीत किया जा सकता है विकसित कर सकते हैं, लेकिन कई मामलों में काम की जरूरत है और/या अंतिम परिणाम काफी लायक नहीं हैं।

मेरे दो सेंट।

Answer 8

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

Answer 9

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

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

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

Answer 10

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

यही कारण है कि आप इसे देख रहे हैं, व्यावहारिक रूप से, एसक्यूएल में, सभी शामिल हैं स्पष्ट हैं।

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

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

आप ऑप्टिमाइज़र द्वारा विदेशी कुंजी में उन्मूलन में this article में रुचि भी ले सकते हैं।

Answer 11

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

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

Answer 12

अच्छा सवाल। मैं हमेशा सोचा है कि एसक्यूएल

SELECT tbl1.col1, tbl2.col2 
    FROM tbl1 
    JOIN tbl2 USING(FK_tbl1_tbl2) 

की तरह एक वाक्य रचना नहीं है जहां FK_tbl1_tbl2 तालिकाओं के बीच कुछ विदेशी कुंजी बाधा है है। यह अविश्वसनीय रूप से अधिक उपयोगी होगा कि प्राकृतिक जॉइन या ओरेकल का उपयोग (col1, col2)।

Answer 13

मैं उन क्षेत्रों द्वारा तालिकाओं में शामिल होने की आवश्यकता की कल्पना नहीं कर सकता जो एफके नहीं हैं। क्या कोई ऐसा उदाहरण दे सकता है जो समझ में आता है?

FOREIGN KEY ही रेफेरेंन्शिअल सत्यनिष्ठा लागू करने के लिए करता है, तो ER मॉडल की संस्थाओं के बीच संबंध संबंधपरक मॉडल में दो संबंधों के बीच एक equijoin साथ देखा जा सकता है इस्तेमाल किया जा सकता।

यह हमेशा सत्य नहीं होता है।

और:

• What is entity-relationship model?

यह मॉडल माल और मूल्य श्रेणियों में बताता है:

यहाँ एक उदाहरण अपने ब्लॉग में लेख से मैं कुछ समय पहले लिखा है यहां मॉडल का संबंधपरक कार्यान्वयन है:

CREATE TABLE Goods (ID, Name, Price) 
CREATE TABLE PriceRange (Price, Bonus) 

आप देख सकते हैं, PriceRange तालिका केवल एक ही कीमत से संबंधित विशेषता, Price है, लेकिन मॉडल दो विशेषताएँ हैं: StartPrice और EndPrice।

ऐसा इसलिए है क्योंकि संबंध मॉडल सेट को बदलने की अनुमति देता है और इकाई PriceRange को आसानी से SQL संचालन का उपयोग करके पुनर्निर्मित किया जा सकता है।

Goods 
ID Name    Price 
1 Wormy apple  0.09 
2 Bangkok durian  9.99 
3 Densuke watermelon 999.99 
4 White truffle  99999.99 

PriceRange 
Price Bonus 
0.01  1% 
1.00  3% 
100.00 10% 
10000.00 30% 

हम केवल प्रत्येक सीमा के निचले बाउंड को स्टोर करते हैं। ऊपरी बाउंड आसानी से अनुमान लगाया जा सकता है।

यहाँ प्रत्येक अच्छे के लिए बोनस को खोजने के लिए क्वेरी है:

SELECT * 
FROM Goods 
JOIN PriceRange 
ON  PriceRange.Price = 
     (
     SELECT MAX(Price) 
     FROM PriceRange 
     WHERE PriceRange.Price <= Goods.Price 
     ) 

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

Answer 14

मुख्य कारण उनके (Navicat, MySQL, आदि) सबसे MySQL जीयूआई उपकरण में एक प्रश्न

बेवकूफ ध्वनि, लेकिन मैं मैं डॉन के बाद से और साथ ही इस बात का दोषी हूँ बिना सेट करने के लिए कोई रास्ता नहीं है 'टी वाक्य रचना याद है: मेरे लिए यह की/

Answer 15

भाग कि है (और हाँ, यह एक लंगड़ा बहाना नहीं है) विदेशी कुंजी जोड़ने के लिए एमएस के एसक्यूएल सर्वर प्रबंधन स्टूडियो में यूआई भयंकर है।

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

हर बार जब मुझे एक विदेशी कुंजी बनाना पड़ता है, तब तक परीक्षण और त्रुटि होती है जब तक कि यह काम नहीं करता।

Answer 16

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

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

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

माइकल

Answer 17

विदेशी कुंजी युग्मन है। प्रोग्रामिंग में, युग्मन शायद ही कभी अच्छा है।