कुछ बिंदु:
ऐसा लगता है कि आप तालिका के बारे में वर्तमान में अद्वितीय चीज़ों का उपयोग कर रहे हैं और इसे प्राथमिक कुंजी के रूप में बना रहे हैं। यह काम करता है। और जब स्थानीयता के कारण पूछताछ की बात आती है तो प्राकृतिक चाबियों के कुछ फायदे होते हैं। (प्रत्येक उपयोगकर्ता का डेटा उसी क्षेत्र में संग्रहीत किया जाता है)। और क्योंकि तालिका उस कुंजी द्वारा क्लस्टर की जाती है जो डेटा को लुकअप को समाप्त कर देती है यदि आप प्राथमिक में कॉलम द्वारा खोज रहे हैं।
-
लेकिन, आपके द्वारा चुनी गई प्राकृतिक प्राथमिक कुंजी का उपयोग करने से प्रदर्शन के नुकसान भी होते हैं।
-
एक बहुत बड़ी प्राथमिक कुंजी का उपयोग करने से अन्य सभी अनुक्रमणिका innodb में बहुत बड़ी हो जाएंगी क्योंकि प्राथमिक कुंजी प्रत्येक अनुक्रमणिका मान में शामिल होती है।
-
प्राकृतिक प्राथमिक कुंजी का उपयोग करना INSERT के लिए सरोगेट कुंजी जितना तेज़ नहीं है क्योंकि बड़ा होने के अलावा यह हर बार तालिका के अंत में सम्मिलित नहीं हो सकता है। इसे उस उपयोगकर्ता और पोस्ट आदि के लिए अनुभाग में सम्मिलित करना होगा।
-
साथ ही, यदि आप समय के अनुसार खोज कर रहे हैं तो सबसे अधिक संभावना है कि आप टेबल पर प्राकृतिक कुंजी के साथ खोज रहे होंगे जब तक कि समय आपका पहला कॉलम न हो। सरोगेट कुंजियाँ समय के लिए स्थानीय होती हैं और अक्सर कुछ प्रश्नों के लिए सही हो सकती हैं।
-
प्राथमिक कुंजी के रूप में आपकी जैसी प्राकृतिक कुंजी का उपयोग करना भी कष्टप्रद हो सकता है। क्या होगा यदि आप किसी विशेष वोट का उल्लेख करना चाहते हैं? आपको कुछ फ़ील्ड चाहिए। साथ ही बहुत सारे ओआरएम के साथ इसका उपयोग करना थोड़ा मुश्किल है।
यहां उत्तर दिया गया है
मैं आपकी खुद की सरोगेट कुंजी बनाउंगा और इनोडब की आंतरिक प्राथमिक कुंजी पर भरोसा करने के बजाय इसे प्राथमिक कुंजी के रूप में उपयोग करूंगा क्योंकि आप इसे अपडेट और लुकअप के लिए उपयोग करने में सक्षम होंगे।
ALTER TABLE tbl_rate
ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY(id);
लेकिन, यदि आप एक सरोगेट प्राथमिक कुंजी बनाते हैं, तो मैं आपकी कुंजी को एक अद्वितीय बना दूंगा। वही लागत लेकिन यह शुद्धता को लागू करती है।
ALTER TABLE tbl_rate
ADD UNIQUE ( user_id, post_id, type );
