sql - प्राथमिक कुंजी के बिना तालिका बनाने के लिए एक बुरा विचार क्यों है?




sql-server entity-framework entity-framework-6 (4)

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

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

किसी भी अंतर्दृष्टि के रूप में मैं इसे सर्वोत्तम अभ्यासों का पालन करने के लिए कैसे बदल सकता हूं, और यह क्यों शुरू करने के लिए सर्वोत्तम प्रथाओं के खिलाफ है?


Answers

यह प्रतिक्रिया मुख्य रूप से राय / अनुभव-आधारित है, इसलिए मैं दिमाग में आने वाले कुछ कारणों की सूची करूँगा। ध्यान दें कि यह संपूर्ण नहीं है

यहां कुछ कारण दिए गए हैं कि आपको प्राथमिक कुंजी (पीके) का उपयोग क्यों करना चाहिए:

  1. वे आपको तालिका में दिए गए पंक्ति को विशिष्ट रूप से पहचानने के लिए एक रास्ता प्रदान करने की अनुमति देते हैं ताकि यह सुनिश्चित हो सके कि कोई डुप्लिकेट नहीं हैं।
  2. RDBMS आपके लिए इस बाध्यता को लागू करता है, इसलिए आपको डालने से पहले डुप्लिकेट की जांच करने के लिए अतिरिक्त कोड लिखना नहीं है, एक पूर्ण तालिका स्कैन से बचने के लिए, जो यहां बेहतर प्रदर्शन का मतलब है
  3. पीके आप उन तालिकाओं के बीच संबंध बनाने के लिए विदेशी कुंजी (एफके) बनाने की अनुमति देते हैं जिससे RDBMS "जागरूक" हो। पीके / एफके के बिना, रिश्ते केवल प्रोग्रामर के दिमाग में ही मौजूद होते हैं, और संदर्भित तालिका में "पीके" हटाए जाने के साथ एक पंक्ति हो सकती है, और "एफके" के साथ दूसरी तालिका अब भी सोचती है कि "पीके" मौजूद है। यह बुरा है, जो अगले बिंदु की ओर जाता है
  4. यह आरडीबीएमएस को अखंडता की बाधाओं को लागू करने की अनुमति देता है क्या TableA.id को TableB.table_a_id द्वारा संदर्भित किया TableB.table_a_id ? यदि TableB.table_a_id = 5 , तो आप TableA में id = 5 साथ एक पंक्ति रखने की गारंटी लेते हैं। डाटा अखंडता और स्थिरता बनाए रखा है, और यह अच्छा है।
  5. इससे RDBMS को तेजी से खोज करने की अनुमति मिलती है बी / सी पीके फ़ील्ड अनुक्रमित होती हैं, जिसका अर्थ है कि किसी तालिका की खोज करने के दौरान उसकी सभी पंक्तियों को चेक करने की आवश्यकता नहीं होती है

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

इसमें और कारण भी हैं, लेकिन मुझे आशा है कि इससे आपको इसके माध्यम से काम करने के लिए पर्याप्त होगा।

जहां तक ​​आपका M:M रिश्तों को जाता है, आपको सहयोगी तालिकाओं को बनाने की आवश्यकता होती है और आप इसमें एक समग्र पीके बना सकते हैं, पीके दूसरे 2 तालिकाओं के 2 पीके का संयोजन है।

दूसरे शब्दों में, अगर टेबल A और B बीच एक M:M रिलेशन्स है, तो हम एक मेज C बनाते हैं, जिसमें एक तालिका 1:M दोनों तालिकाओं के साथ A । "ग्राफ़िक रूप से", यह इसके जैसा दिखता था:

+---+ 1  M +---+ M  1 +---+
| A |------| C |------| B |
+---+      +---+      +---+

C टेबल पीके के साथ कुछ हद तक इस तरह:

+-----+
|  C  |
+-----+
| id  |  <-- C.id = A.id + B.id (i.e. combined/concatenated, not addition!)
+-----+

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

उदाहरण के लिए, HelloCity केवल User और City लिए आईडी संग्रहीत करता है। क्यूं कर? चूंकि यह City बारे में सभी डेटा और अन्य तालिका में User बारे में सभी डेटा पुनः रिकॉर्ड करने के लिए बेवकूफ होगा क्योंकि जब आप पहले से ही इसे कहीं और संग्रहीत कर चुके हैं इसका सौंदर्य यह है कि उपयोगकर्ता को किसी कारण के लिए उनके DisplayName को अपडेट करने की आवश्यकता है। ऐसा करने के लिए, आपको इसे उपयोगकर्ता में बदलने की आवश्यकता है अब, उपयोगकर्ता को संदर्भित करने वाली कोई पंक्ति तुरन्त नया DisplayName ; अन्यथा आपको पुराने प्रदर्शन नाम का उपयोग करके हर रिकॉर्ड को ढूंढना होगा और तदनुसार अपडेट करना होगा, जो बड़े डेटाबेस में काफी समय ले सकता है।

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

प्राथमिक कुंजी की मदद के लिए एक और तरीका है कि वे अपने कॉलम (एस) पर एक इंडेक्स उत्पन्न करते हैं। इससे क्वेरी में कार्यक्षमता बढ़ जाती है जहां आपके WHERE क्लॉज प्राथमिक कुंजी कॉलम मान पर खोज करता है। और, जब से आप अन्य तालिकाओं में उस प्राथमिक कुंजी का जिक्र कर रहे होंगे, यह उस लुकअप को और भी तेज बनाता है।

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

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

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


प्राथमिक कुंजी के लिए दो प्राथमिक कारण:

  1. बाद के संदर्भ के लिए एक रिकॉर्ड की विशिष्ट पहचान करने के लिए
  2. अन्य तालिकाओं में सही और कुशलता से शामिल होने के लिए

सबसे पहले आपको समझने की जरूरत है कि दोनों अलग-अलग चीजें हैं। संग्रहीत प्रक्रियाओं का सर्वोत्तम उपयोग INSERT-UPDATE-DELETE कथन के लिए किया जाता है। और दृश्य चयन कथन के लिए उपयोग किया जाता है। और आपको दोनों का उपयोग करना चाहिए।

विचारों में आप डेटा को बदल नहीं सकते हैं।





sql sql-server entity-framework entity-framework-6