एकाधिक टेबल और कॉलम के लिए विदेशी कुंजी?

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

CREATE TABLE user(
  id INT(11) NOT NULL AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL,
  password VARCHAR(20) NOT NULL,
  PRIMARY KEY (id)
);

CREATE TABLE items(
  i_id INT(11) NOT NULL AUTO_INCREMENT,
  name TINYTEXT NOT NULL,
  price DECIMAL(8,2) NOT NULL,
  PRIMARY KEY (i_id)
);

CREATE TABLE user_purchase(
  i_id INT(11) NOT NULL,
  name TINYTEXT NOT NULL,
  id INT(11) NOT NULL,
  FOREIGN KEY (i_id) REFERENCES items(i_id),
  FOREIGN KEY (id) REFERENCES user(id)
);

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

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

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

यह एक तरह की विसंगति है।

इसके कई प्रकार हैं, जहां तक ​​हो सके इनसे बचना ही बेहतर है।

विसंगतियों के बारे में यहां और पढ़ें

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

सामान्यीकरण का विवरण विभिन्न सामान्य रूपों के विषयों द्वारा कवर किया जाता है:NF0, NF1, NF2, NF3 और BCNF

विस्तृत रूप में सामान्य रूप

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

कार्यात्मक निर्भरता