प्राथमिक कुंजी / विदेशी कुंजी मिलानों के लिए उपयोग क्यों नहीं किए जाते हैं?

Question

जहाँ तक मुझे कई DBMS (जैसे mysql, postgres, mssql) पता लगा सकते हैं, केवल डेटा में परिवर्तन को बाधित करने के लिए fk और pk संयोजनों का उपयोग करते हैं, लेकिन वे शायद ही कभी मूल रूप से जुड़ने के लिए कॉलम का चयन करते हैं (जैसे कि प्राकृतिक नाम नामों के साथ होता है)। ऐसा क्यों है? यदि आप पहले से ही एक pk / fk के साथ 2 तालिकाओं के बीच संबंध निर्धारित कर चुके हैं, तो डेटाबेस यह पता नहीं लगा सकता है कि यदि मैं उन तालिकाओं में शामिल हो जाऊं, जिन्हें मैं pk / fk कॉलम में शामिल करना चाहता हूं?

संपादित करें: इसे थोड़ा स्पष्ट करने के लिए:

मान लीजिए कि मेरे पास एक टेबल 1 और एक टेबल 2 है। टेबल 1 में कॉलम ए पर एक विदेशी कुंजी है, जो टेबल 2 पर प्राथमिक कुंजी, कॉलम बी के संदर्भ में है। अब अगर मैं इन तालिकाओं में शामिल होता हूं, तो मुझे ऐसा कुछ करना होगा:

SELECT * FROM table1
JOIN table2 ON table1.a = table2.b

हालाँकि, मैंने पहले से ही अपनी कुंजियों का उपयोग करते हुए परिभाषित किया है कि table1.a का संदर्भ table2.b पर है, इसलिए मुझे ऐसा लगता है कि DBMS सिस्टम को स्वचालित रूप से table1.a और table2.b में शामिल होने वाले कॉलम के रूप में उपयोग करने के लिए कठिन नहीं होना चाहिए, ऐसा है कि एक बस का उपयोग कर सकते हैं:

SELECT * FROM table1
AUTO JOIN table2

हालाँकि, कई DBMS इस तरह से कुछ लागू नहीं करते हैं।

Answer 1

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

हालांकि, एक गंभीर खामी है! क्वेरीज़ जो आज सही हैं, कल उसी तालिका में एक दूसरा FK जोड़कर एक त्रुटि हो सकती है!

मुझे फिर से कहना है: स्तंभों को जोड़कर, उन स्तंभों का उपयोग न करने वाले प्रश्न 'सही' से 'त्रुटि' में बदल सकते हैं!

यह एक ऐसा मेंटेनेंस दुःस्वप्न है, कि कोई भी सेंस स्टाइल गाइड इस सुविधा का उपयोग करने के लिए निषिद्ध होगा। अधिकांश पहले select *से ही एक ही कारण के लिए निषेध !

यह सब स्वीकार्य होगा, अगर प्रदर्शन बढ़ाया जाएगा। हालाँकि, यह मामला नहीं है।

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

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

Comments

वास्तव में एक छोटा सा प्रदर्शन हिट होगा क्योंकि इसमें जुड़ने वाले स्तंभों को अंकुरित करने के बजाय उन्हें लगाना होगा।

— HLGEM

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

— पचेरियर

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

— जे के

कई मामलों? एक हजार टेबल डीबी पर, मेरे पास केवल दो टेबल के बीच अधिक से अधिक -1 संबंध के कुछ मामले हैं। वैसे भी, यह कोई समस्या नहीं है, यह रिश्ता नाम जोड़ने के लिए पर्याप्त AUTO JOIN mytable THROUGH myrelationहोगा, यह बहुत अच्छा होगा।

— तीजय

हम अपने कस्टम-बिल्ट .NET SQL बिल्डर में इंटैलिजेंस के साथ ऐसा करते हैं, जैसेInnerJoin(SRC_TABLE.rDEST_TABLE.REL_NAME_F01)

— Teejay

Answer 2

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

1. आपके पास एक ही तालिका में कई विदेशी कुंजियाँ हो सकती हैं। निम्नलिखित पर विचार करें जहां एक शिपमेंट में एक प्रारंभिक बिंदु और एक समाप्ति बिंदु है।

   table: USA_States
   StateID
   StateName
   
   table: Shipment
   ShipmentID
   PickupStateID Foreign key
   DeliveryStateID Foreign key

   आप पिकअप स्थिति के आधार पर शामिल होना चाह सकते हैं। हो सकता है कि आप डिलीवरी की स्थिति में शामिल होना चाहते हों। शायद आप दोनों के लिए 2 जुड़ाव प्रदर्शन करना चाहते हैं! Sql इंजन में यह जानने का कोई तरीका नहीं है कि आप क्या चाहते हैं।

2. आप अक्सर स्केलर मान में शामिल हो जाएंगे। हालांकि स्केलर्स आमतौर पर मध्यवर्ती गणनाओं का परिणाम होते हैं, कभी-कभी आपके पास एक विशेष उद्देश्य तालिका होगी जिसमें ठीक 1 रिकॉर्ड होगा। यदि इंजन में शामिल होने के लिए एक foriegn कुंजी का पता लगाने की कोशिश की .... यह समझ में नहीं आता क्योंकि क्रॉस जॉइन कभी भी एक कॉलम से मेल नहीं खाता।

3. कुछ विशेष मामलों में आप उन स्तंभों से जुड़ेंगे जहाँ न तो अद्वितीय है। इसलिए उन स्तंभों पर पीके / एफके की उपस्थिति असंभव है।

4. आप सोच सकते 2 अंक और 3 के ऊपर प्रासंगिक के बाद से अपने प्रश्नों जब वहाँ बारे में है नहीं कर रहे हैं है एक भी पी / FK तालिकाओं के बीच संबंध। हालाँकि तालिकाओं के बीच सिंगल PK / FK की उपस्थिति का मतलब यह नहीं है कि आपके पास PK / FK के अलावा अन्य फ़ील्ड से जुड़ने की आवश्यकता नहीं है। Sql इंजन को नहीं पता होगा कि आप किन क्षेत्रों से जुड़ना चाहते हैं।

5. कहते हैं कि आपके पास एक तालिका "USA_States" है, और 5 अन्य तालिकाओं के साथ राज्यों के लिए FK है। "पाँच" तालिकाओं में भी एक दूसरे के लिए कुछ विदेशी कुंजियाँ होती हैं। क्या sql इंजन स्वचालित रूप से "USA_States" के साथ "पांच" तालिकाओं में शामिल होना चाहिए? या यह एक दूसरे से "पांच" में शामिल होना चाहिए? दोनों? आप रिश्तों को स्थापित कर सकते हैं ताकि एसक्यूएल इंजन एक अनंत लूप में प्रवेश करे और सामान को एक साथ जोड़ने की कोशिश करे। इस स्थिति में यह असंभव है कि आप क्या चाहते हैं, इसका अनुमान लगाने के लिए sql इंजन है।

सारांश में: पीके / एफके का टेबल जॉइन से कोई लेना-देना नहीं है। वे अलग-अलग असंबंधित चीजें हैं। यह केवल प्रकृति का एक दुर्घटना है जिसे आप अक्सर पीके / एफके कॉलम में शामिल करते हैं।

क्या आप चाहते हैं कि sql इंजन यह अनुमान लगाए कि क्या यह पूर्ण, बाएँ, दाएँ, या आंतरिक जुड़ाव है? मुझे ऐसा नहीं लगता। हालाँकि यह निश्चित रूप से कॉलम में शामिल होने का अनुमान लगाने की तुलना में कम पाप होगा।

Comments

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

आपके तर्क तब पकड़ते हैं जब सामान्य JOIN कीवर्ड हमेशा मैच करने की कोशिश करता है (जैसा कि मैंने अपने उदाहरण में गलत किया, मैं इसे ठीक कर दूंगा)। हालाँकि, कई जॉइन केवल सीधे जॉइन से प्राप्त किए जा सकते हैं , इसलिए मुझे कोई कारण नहीं दिखता है कि उनके साथ जुड़ने के लिए कोई स्पष्ट वाक्यविन्यास क्यों नहीं हो सकता है। कई डीबीएमएस में एक प्राकृतिक जुड़ाव होता है, जो मूल रूप से एक ही काम करता है लेकिन कॉलम नामों (= खराब) के साथ। एक ही बात इस तरह के जुड़ने के साथ की जा सकती है, जैसे कि AUTO JOIN ऑपरेशन को निर्दिष्ट करके।

"यह सिर्फ प्रकृति का एक दुर्घटना है जिसे आप अक्सर पीके / एफके कॉलम पर जोड़ते हैं" - मुझे यकीन नहीं है!

— onedaywhen

"सामान्यीकरण?" मुझे लगता है कि यहाँ सोच यह है कि अगर आपने 1NF relvar से शुरुआत की है तो 6NF relvars में विघटित हो जाते हैं तो संभावना है कि a) उनके पास कार्यान्वयन पर विदेशी कुंजी होगी और b) वे अक्सर प्रश्नों में शामिल हो जाएंगे।

— onedaywhen

मुझे लगता है कि अगर वहाँ "PK / FK तालिका में शामिल होने के साथ कुछ

— ypercube y

Answer 3

"जुड़ाव" की अवधारणा। संबंध r1और r2जुड़ने योग्य हैं, यदि केवल और केवल एक ही नाम वाले गुण एक ही प्रकार के हैं ... यह अवधारणा न केवल इस तरह से बल्कि विभिन्न अन्य परिचालनों [जैसे कि संघ] में भी शामिल होने के लिए लागू होती है।

एसक्यूएल और रिलेशनल थ्योरी: सीजे तारीख तक सटीक एसक्यूएल कोड कैसे लिखें

मानक SQL में पहले से ही एक ऐसी सुविधा है, जिसे NATURAL JOINmySQL के रूप में जाना जाता है और इसे लागू किया गया है।

हालांकि आपका सुझाव काफी योग्य नहीं है, यह उचित लगता है। SQL सर्वर (जिसके लिए समर्थन की कमी हैNATURAL JOIN ) के साथ, मैं प्रबंधन स्टूडियो में SQL प्रॉम्प्ट का उपयोग करता हूं: जब INNER JOINइसकी इंटेलीजेंस लिखता है, तो ONदोनों सामान्य विशेषता नामों और विदेशी कुंजियों के आधार पर क्लॉज का सुझाव देते हैं और मुझे यह बहुत उपयोगी लगता है। हालांकि, इसके लिए एक नए (मानक) एसक्यूएल जॉइन प्रकार को देखने की मेरी कोई इच्छा नहीं है।

Comments

सामान्य स्तंभों पर प्राकृतिक जुड़ना और जुड़ना FK-PK पर जुड़ने की धारणा से भिन्न है। (मेरा उत्तर देखें।)

— २२:०४ पर दीक्षा

@philipxy: सहमत, मैं अन्यथा का मतलब नहीं था। (आपका उत्तर एक उत्कृष्ट उत्तर है!)

— १३

Answer 4

एसक्यूएल पहले आया!

विदेशी कुंजी और विदेशी कुंजी बाधाएं बाद में आईं और अनिवार्य रूप से "लेनदेन" शैली के अनुप्रयोगों के लिए एक अनुकूलन हैं।

संबंधपरक डेटाबेस को मूल रूप से डेटा के सेट पर जटिल प्रश्नों को लागू करने के तरीके के रूप में माना गया था जो कि रिलेशनल बीजगणित का उपयोग करके गणितीय रूप से सिद्ध किया गया था । IE डेटा के दिए गए सेट और दिए गए क्वेरी के लिए हमेशा एक ही सही उत्तर होता है।

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

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

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

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

Comments

धन्यवाद, यह मेरे लिए समझ में आया! हालांकि, प्राकृतिक जोड़ों में समान समस्याएं नहीं हैं? हालांकि प्राकृतिक जुड़ाव भी बड़ी समस्याएँ हैं, कई DBMS उनका समर्थन करते हैं। IMO pk / fk पर आधारित एक जॉइन सही में किया जाने वाला एक प्राकृतिक जॉइन होगा।

जहाँ तक अधिकांश डेटाबेस इंजनों के स्वाभाविक जुड़ाव और एक स्पष्ट "JOIN ... ON" के बीच का अंतर नहीं है। इंजन क्वेरी का विश्लेषण करता है और विभिन्न विधेयकों के आधार पर इसमें सबसे अच्छा शामिल होता है। एक स्पष्ट जुड़ाव का उपयोग किसी विशेष सूचकांक या पहुंच पथ के उपयोग को बाध्य नहीं करता है, इसका वहां ज्यादातर "LEFT, OUTER, INNER" का समर्थन करने के लिए सिंटैक्स शामिल होता है, जिसे "लापता" पंक्ति सम्मिलित करने के लिए जानने के लिए स्पष्ट रूप से शामिल होने के लिए स्पष्ट रूप से शामिल होने की आवश्यकता होती है। ।

एसक्यूएल पहले नहीं आया! संबंधपरक मॉडल (जिसमें निश्चित रूप से विदेशी कुंजी की अवधारणा शामिल थी) को पहली बार 1969 में EFCodd द्वारा उल्लिखित किया गया था। SEQUEL, जैसा कि तब था, 1974 के आसपास तक दिन का प्रकाश नहीं देखा गया था। इसके अन्वेषकों ने इसे स्पष्ट रूप से स्पष्ट किया था SEQUEL / SQL का इरादा पहले से मौजूद रिलेशनल मॉडल पर आधारित था - हालाँकि SQL वास्तव में रिलेशनल भाषा होने के नाते कम था।

— nvogel

@sqlvogel - सच! इसे फिर से बनाना चाहिए "SQL पहले लागू किया गया था"।

— जेम्स एंडरसन

सीजे डेट इन 'एन इंट्रोडक्शन टू डेटाबेस सिस्टम्स' (पी 276) कहता है कि कोडड ने विदेशी कुंजी की अवधारणा का आविष्कार किया था; कहते हैं, लेकिन जब मैं पहले SQL कार्यान्वयन से पहले था मान नहीं है।

— onedaywhen

Answer 5

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

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

Answer 6

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

---

अब संपादित करें कि प्रश्न पूरी तरह से फिर से लिखा गया है: आप जिस मामले का वर्णन कर रहे हैं वह केवल प्रश्नों के बहुत छोटे सेट के लिए होगा। क्या होगा अगर 12 टेबल शामिल हैं? क्या होगा अगर कोई एफके नहीं हैं .... भले ही मैं डिफ़ॉल्ट रूप से शामिल हो गया था फिर भी मैं हमेशा पठनीयता के लिए जुड़ाव निर्दिष्ट करूंगा। (मुझे डेटा देखने की जरूरत नहीं है और फिर यह पता लगाने की कोशिश करें कि इसमें क्या शामिल हो रहा है)

कुछ क्वेरी टूल वास्तव में आपके लिए एक ऑटो जॉइन करते हैं, फिर आपको जॉइन को हटाने या संपादित करने की अनुमति देते हैं। मुझे लगता है कि एमएस एक्सेस का क्वेरी बिल्डर ऐसा करता है।

अंत में ANSII मानक कहता है कि जुड़ना निर्दिष्ट होना चाहिए। इसकी अनुमति नहीं देने के लिए यह पर्याप्त है।

Comments

क्षमा करें, शायद मैं पर्याप्त स्पष्ट नहीं था। मैं इंडेक्स की बात नहीं कर रहा, मैं जॉइन की बात कर रहा हूं। मान लीजिए कि मेरे पास table1.a पर एक fk के साथ table1 और table2 है, जो table2.b की ओर इशारा करता है। अगर मैं इन तालिकाओं में शामिल होता हूं, तो मुझे स्पष्ट रूप से यह कहना होगा कि मैं उन्हें कॉलम a और b (जैसे 'SELECT * FROM table1 JOIN table2 ON table1.a = table2.b ') पर जोड़ना चाहता हूं, जबकि मैं अपने डेटाबेस में पहले से ही परिभाषित कर चुका हूं। योजना है कि उन दो संबंधित हैं। सवाल यह है कि मैं 'SELECT * FROM table1 JOIN table2' क्यों नहीं कर सकता और DBMS को स्वचालित रूप से fk / pk के आधार पर जॉइन कॉलम को चुनने दें।

विशेष रूप से पठनीयता ने मुझे समझ में आया! हालाँकि, मानक कहता है कि वास्तव में अच्छा तर्क IMO नहीं है। पहले (HTML उदाहरण के लिए) कई मानकों ने गलत विकल्प बनाए हैं।

Answer 7

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

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

(मेरी पत्नी अभी भी मैनेजमेंट स्टूडियो और एसक्यूएल सर्वर के बीच के अंतर को नहीं समझ सकती है और प्रबंधन स्टूडियो शुरू करने पर एसक्यूएल सर्वर शुरू करने की बात करती है!)

Answer 8

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

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

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

क्या मानव-पठनीय विवरण से SQL क्वेरी बनाने के लिए अंगूठे का कोई नियम है?

Answer 9

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

जैसा कि दूसरों ने बताया है, कुछ कार्यान्वयन एक एक्सटेंशन का उपयोग करते हैं जहां शामिल (स्तंभ) एक सामान्य स्तंभ नाम के आधार पर दो तालिकाओं में जुड़ता है, जो कुछ इसी तरह का है। लेकिन यह व्यापक रूप से नहीं फैला है। ध्यान दें कि यह एक्सटेंशन SELECT * FROM employee NATURAL JOIN department;सिंटैक्स से अलग है जिसमें यह निर्दिष्ट करने का कोई तरीका शामिल नहीं है कि किस कॉलम का उपयोग करना है। न तो तालिकाओं के बीच एक संबंध पर भरोसा करते हैं, जो उन्हें अविश्वसनीय बनाता है (विस्तार से अधिक स्वाभाविक रूप से वाक्य रचना में शामिल होता है)।

"PKFK पर इनर ज्वाइन टेबल" के लिए कोई मौलिक बाधा नहीं है, जहां PKFK एक कीवर्ड अर्थ है "दो तालिकाओं के बीच परिभाषित विदेशी कुंजी संबंध", एक ही तालिका में एकाधिक fk के साथ समस्याएँ हो सकती हैं, लेकिन यह केवल एक त्रुटि का कारण हो सकता है। सवाल यह है कि भाषा को डिजाइन करने वाले लोग मानते हैं कि ए) एक अच्छा विचार और बी) कुछ अन्य भाषा परिवर्तन की तुलना में काम करना बेहतर है ...

Comments

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

@JonathanHobbs: मेरा मतलब था कि मेरा जवाब आम तौर पर तटस्थ होना चाहिए। लेकिन तटस्थता को छोड़ देना। व्यंग्य का तर्क त्रुटिपूर्ण है। तालिकाओं में पहले से ही क्वेरीज़ को तोड़ने के लिए, एक मेज पर एक नया कॉलम जोड़ने से प्राथमिक कुंजी या तो क्वेरीज़ में जा रही है या गलत परिणाम देना शुरू कर रही है। यह वास्तव में आपको एक हद तक इंसुलेट करता है, जब तक कि टेबल रिलेशनशिप को बनाए रखा गया था, कॉलम में बदलाव सुरक्षित रूप से किया जा सकता था। यह संभवत: FK संबंधों का उपयोग बढ़ाएगा, क्योंकि यह RI.Most जॉइन के अलावा किसी अन्य चीज के लिए उपयोगी होगा। या तो PK पर हैं या Pk.To को मल्टी fk हैंडल में शामिल करते हैं, कॉलम नाम का उपयोग करें।

— जोर्मेनो

Answer 10

यदि संदर्भ खंड को संदर्भित करने के लिए संदर्भित अखंडता के आधार पर खेतों का अनुसरण किया जाता है, तो आप कार्टेशियन उत्पाद कैसे करेंगे?

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

अब आपको क्या करना है, यह तय करने के लिए कि आपके सभी ऑटो अपने रिलेशनशिप स्टेटमेंट के इरादे से मेल खाने के लिए रिलेशनशिप में बदलाव करते हैं।

Comments

@ जेफ़ो: मुख्य लाभ यह है कि यह बहुत स्पष्ट घोषणात्मक तरीके से इरादे को अधिक सटीक रूप से व्यक्त करता है। कॉलम के नामों में शामिल होने से आपको कुछ भी नहीं पता चलता है, इस तथ्य के अलावा कि कॉलम की कुछ सामग्री दूसरे में भी समान है (लेकिन एक ही प्रकार की नहीं हो सकती है)। एक, एक FK रेफरी पर शामिल होने आपको बताता है कि वहाँ है एक FK रेफरी, कोई स्तंभ सूची का मतलब होगा वहाँ था तालिकाओं के बीच केवल 1 FK, या इसके विपरीत है कि वहाँ 1 + (1 से अधिक रेफरी क्या जब होता है के साथ एक multicolumn कुंजी पर विचार आप कॉलम c1 = fk1_c1 और c2 = fk2_c2) को मिलाते हैं। औसत से अधिक टाइपिंग के साथ, यह अच्छा होगा।

— जोर्मेनो

(INNER) JOIN ऑन का उपयोग करना मानक SQL नहीं है। कोमा, क्रॉस जॉइन और (INNER या किसी भी कंप्यूटर) पर शामिल हों 0 = 0 कार्टेशियन उत्पाद लौटाएं।

— फिलीपिक्सी

Answer 11

डेटाबेस यह पता नहीं लगा सकता है कि अगर मैं उन तालिकाओं में शामिल हो जाऊँ जो मैं उन्हें pk / fk कॉलम में शामिल करना चाहता हूँ?

कारण के भाग हैं:

1 - सिद्धांत में आप दो तालिकाओं से मनमानी कॉलम पर तालिकाओं में शामिल हो सकते हैं। हालांकि यह सामान्य अभ्यास नहीं है, यह मान्य है। याद रखें कि एसक्यूएल एक प्रोग्रामिंग भाषा की तरह है, यह समझ में नहीं आता है कि एसक्यूएल के लिए पाठ्यक्रम और नामों के कॉलम के अंदर क्या जानकारी है, इस संबंध में ज्यादा मतलब नहीं है।

2 - अलग-अलग प्रकार के जोड़ होते हैं (बाएं, रे, आंतरिक) - इनर जॉइन उनमें से केवल 1 है।

3 - एसक्यूएल मानक को निम्न-स्तरीय भाषा होने के सिद्धांत द्वारा निर्देशित किया जा सकता है जो उच्च स्तरीय बोलियों को इसका उपयोग करके बुद्धिमता का निर्माण करने की अनुमति देता है। तुलना कुछ हद तक स्पष्ट है यदि आप एक 4 वीं पीढ़ी की भाषा बनाम एक 3 पीढ़ी की भाषा के बारे में सोचते हैं। वास्तव में, एक उपकरण जिसका मैंने उपयोग किया है, IEF, ने आपको कुछ इस तरह लिखने की अनुमति दी है:

ReadEach Customer 
Where Customer Places Orders and That Customer LivesIn "California" 
and OrderValue > 100.00

सारांश में आपका सुझाव दिलचस्प है और इसे मानक के हिस्से के रूप में या एक संग्रहीत प्रक्रिया के रूप में लागू किया जा सकता है (यह इनर जॉइन के लिए डिफ़ॉल्ट होगा)।

Answer 12

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

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

विदेशी चाबियां, फिर ... इतना आसान नहीं है। वे संबंधपरक मॉडल में एक महत्वपूर्ण अवधारणा हैं , ठीक है, लेकिन उसी नाम के साथ SQL सुविधा अच्छी तरह से तुलना नहीं करती है।

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

क्या यह भ्रामक है?
हाँ।

क्या 30 साल के लोगों को गुमराह करने के बाद, वे इसे और अधिक शक्तिशाली बनाने जा रहे हैं?
कोई मौका नहीं।

आवश्यक होने तक पूरी तरह से विदेशी कुंजी की अनदेखी ... मेरे लिए निर्धारित एसक्यूएल?
हाँ!

और क्यों यह सब पहली जगह में हुआ?
खैर, जिस सुविधा को हम विदेशी कुंजी कहते हैं , उसे बाद में SQL में जोड़ा गया; एसक्यूएल एक मानक है जो समय के साथ-साथ नीचे-ऊपर विकसित होता है। विक्रेताओं ने आकर्षक सुविधाओं को लागू किया, जबकि मानक निकायों का सामना करना पड़ा।

जैसा कि कहा गया है, विदेशी कुंजी, जहां केवल अनुक्रमण के लिए अभिप्रेत था और इसमें कोई JOIN निर्माण उपलब्ध नहीं था। (जहां SELECTजिज्ञासाओं के साथ किया जाता है , JOINप्रश्न काफी हाल ही में हैं और केवल उर्फ SELECTकार्यक्षमता के लिए हैं) वे शायद उस अनुक्रमण झंडे को कॉल करते हुए FOREIGN KEY, रिलेशनल डीबी सिद्धांत अवधारणाओं पर एक चतुर नामकरण-हैक थे।

Comments

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

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

— jmoreno