चरित्र बनाम पूर्णांक प्राथमिक कुंजी

Question

मैं मुख्य संस्थाओं की संभावित विशेषताओं वाले कई लुकअप तालिकाओं के साथ एक डेटाबेस डिजाइन कर रहा हूं। मैं एक ऑटो-इन्क्रीमेंटिंग पूर्णांक के बजाय इन लुकअप मानों की पहचान करने के लिए 4 या 5-कैरेक्टर की का उपयोग करने के बारे में सोच रहा हूं ताकि जब मैं इन विशेषताओं आईडी को मुख्य तालिकाओं पर संग्रहीत करूं तो मुझे केवल यादृच्छिक संख्याओं के बजाय सार्थक मान दिखाई देंगे।

पूर्णांक के बजाय प्राथमिक फ़ील्ड के रूप में वर्ण फ़ील्ड का उपयोग करने के प्रदर्शन निहितार्थ क्या हैं?

अगर वह मायने रखता है तो मैं MySQL का उपयोग कर रहा हूं।

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

      CUISINES
 ID      Description
-----  --------------
CHNSE  Chinese
ITALN  Italian
MXICN  Mexican

Answer 1

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

इससे भी महत्वपूर्ण बात, यह उन उपयोगों पर निर्भर करता है जिनके लिए आप प्राथमिक कुंजी डालेंगे। पूर्णांक सीरियलों का उपयोग करने और लागू करने के लिए सरल होने का लाभ है। वे भी, क्रमांकन विधि के विशिष्ट कार्यान्वयन के आधार पर, जल्दी से व्युत्पन्न होने का लाभ होता है, क्योंकि अधिकांश डेटाबेस केवल सीरियल नंबर को एक निश्चित स्थान पर संग्रहीत करते हैं, बजाय इसे Select max(ID)+1 from fooमक्खी के साथ प्राप्त करने के ।

प्रश्न यह बन जाता है: 5 वर्ण कुंजी आपके और अनुप्रयोग के लिए "सार्थक मूल्य" कैसे प्रस्तुत करती है? यह मान कैसे बनाया गया है, और एक वृद्धिशील क्रम संख्या खोजने से अधिक या कम समय लगता है। जबकि कुछ पूर्णांकों में एक तुच्छ मात्रा में जगह बचती है, अधिकांश सिस्टम इस स्थान की बचत को अनदेखा कर देंगे।

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

वैकल्पिक रूप से, यदि आप सिर्फ मूल देश से ट्रैकिंग कर रहे हैं, और विशिष्ट क्षेत्रीय व्यंजनों (कैंटोनीज़, सिचुआन, सिसिली, यूम्ब्रियन, कैलाब्रियन, युकाटन, ओक्साकन, आदि), तो आप हमेशा आईएसओ 313 कोड का उपयोग कर सकते हैं ।

अगर मेरे पास 10,000 व्यंजनों में 5-वर्ण और 20-वर्ण कुंजी के बीच का अंतर नहीं है, तो क्या जोड़ना है?

स्पेस सस्ता है । जब आप 10,000,000 व्यंजनों पर बात कर रहे हैं, तो आप ओएलएपी ऑपरेशन कर रहे हैं, तब, हो सकता है। 10k व्यंजनों के साथ, आप 150k जगह देख रहे हैं।

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

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

Comments

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

— hobs

Answer 2

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

Answer 3

असली सवाल यह है कि क्या आपके आवेदन (डेटा आकार) के लिए DB क्वेरी प्रदर्शन सभी महत्वपूर्ण है। यदि आपकी क्वेरी माइक्रोसेकंड लेती है, तो Intकुंजी का उपयोग करके उन कुछ माइक्रोसेकंड को सहेजना पठनीयता / रखरखाव की योग्यता के लायक नहीं है। हालांकि, यदि आपकी क्वेरी में मिनट लगते हैं, तो उन कुछ मिनटों को सहेजना Intकुंजी के दर्द के लायक हो सकता है ।

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

यदि आपके पास बहुत सी अनुक्रमिक डेटा (लॉग फाइलें, टाइम सीरीज़, एनालिटिक्स, टेक्स्ट या स्पीच कॉर्पोरा) है, जिसमें आपके किसी भी लुकअप टेबल के लिंक (संबंध) हैं, तो आप पाएंगे कि @ के बावजूद, स्टोरेज स्पेस क्वेरी स्पीड के लिए महत्वपूर्ण है। बॉस्टन-स्टैंटन का सही विश्लेषण कि $ में कितना सस्ता स्थान है। क्योंकि अधिकांश क्वेरी समय (अनुक्रमिक डेटा के लिए) डिस्क को पढ़ने में बिताया जाता है, समय के संदर्भ में स्थान सस्ता नहीं है (समग्र क्वेरी समय के प्रतिशत के रूप में)। इसलिए, जब तक कि आपका RDB स्वचालित रूप से और कुशलतापूर्वक सभी विदेशी कुंजियों (संबंधित अभिलेखों की कुंजियाँ) को संकुचित / विघटित नहीं करता है, तब तक आप चाहते हैं कि आपकी सभी कुंजियाँ Int, जो कि डिस्क स्थान (और पढ़ने की गति) के प्रति सूचना के प्रति यूनिट में सबसे अधिक कुशल हों। सामग्री (एन्ट्रापी)। MySql में FYI करें MyISAM ने प्रतिबंध लगाएआप संपीड़ित डेटा पंक्तियों (केवल पढ़ने के लिए) के साथ क्या कर सकते हैं। दूसरे शब्दों में, स्वचालित रूप से बढ़े हुए पूर्णांक पहले से ही सैद्धांतिक रूप से यथासंभव संपीड़ित हैं , जो कि अधिकांश DB पूर्णांक क्षेत्रों पर कम न्यूनतम आकार की सीमा दी गई है। और वह संपीड़न बिना आता है:

1. क्वेरी-समय संपीड़न / विघटन दंड
2. क्वेरी-टाइम डिस्क पेनल्टी पढ़ें
3. केवल-संकुचित डेटा रिकॉर्ड या कुंजी पर अन्य DB प्रतिबंध पढ़ें

वहाँ एक कारण है कि लोकप्रिय, कुशल ORMs जैसे Django डिफ़ॉल्ट रूप से PKs के लिए ऑटो-इंक्रीमेंटिंग पूर्णांक और क्यों अन्य SO प्रश्न समान निष्कर्ष पर आए हैं।