डेटाबेस डिज़ाइन प्राइमे कुंजी, आईडी बनाम स्ट्रिंग

Question

मैं वर्तमान में एक संगीत स्ट्रीमिंग एप्लिकेशन विकसित करने की योजना बना रहा हूं। और मैं सोच रहा हूं कि सर्वर पर मेरी टेबल में प्राथमिक कुंजी के रूप में बेहतर क्या होगा। एक आईडी int या एक अद्वितीय स्ट्रिंग।

तरीके 1:

गीत तालिका: SongID (पूर्णांक), शीर्षक (स्ट्रिंग), * कलाकार ** (स्ट्रिंग), लम्बाई (पूर्णांक), * एल्बम ** (स्ट्रिंग)

शैली टेबल शैली (स्ट्रिंग), नाम (स्ट्रिंग)

SongGenre: *** SongID **** (पूर्णांक), *** जीई एनआरई **** (स्ट्रिंग)

विधि 2

गीत तालिका: SongID (पूर्णांक), शीर्षक (स्ट्रिंग), * ArtistID ** (पूर्णांक), लम्बाई (पूर्णांक) , * ALBUMID ** (int)

शैली टेबल GenreID (पूर्णांक), नाम (स्ट्रिंग)

SongGenre: *** SongID **** (पूर्णांक), *** GenreID **** (int)

कुंजी: बोल्ड = प्राथमिक कुंजी, * फील्ड ** = विदेशी कुंजी

मैं वर्तमान में विधि 2 का उपयोग कर रहा हूँ डिजाइनिंग के रूप में मैं इस पर विश्वास लुकअप प्रदर्शन को तेज करेगा और कम जगह का उपयोग करेगा क्योंकि एक int स्ट्रिंग के बाद बहुत कम जगह लेता है।

क्या कोई कारण नहीं है कि यह एक अच्छा विचार नहीं है? क्या मुझे कुछ पता होना चाहिए?

Answer 1

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

Answer 2

MSSQL जब किसी पूर्णांक का उपयोग कर आप के लिए इन आईडी के उत्पन्न कर सकते हैं (पहचान कीवर्ड देखें)

Answer 3

मेरे सिफारिश है: आईडी का उपयोग करें।

आप कुछ भी तोड़ने के बिना 20000 गीतों के साथ "शैली" का नाम बदल सकेंगे।

इस के पीछे विचार यह है कि आईडी तालिका में पंक्ति की पहचान करती है। जो कुछ भी पंक्ति है वह ऐसी चीज है जो इस समस्या में कोई फर्क नहीं पड़ता है।

Answer 4

यह व्यक्तिगत प्राथमिकता का मामला है।

मेरी व्यक्तिगत राय और अभ्यास हमेशा पूर्णांक कुंजी का उपयोग करना है और हमेशा प्राकृतिक कुंजी के बजाय सरोगेट का उपयोग करना है (इसलिए कभी भी सामाजिक सुरक्षा संख्या या शैली का नाम जैसे कुछ भी उपयोग न करें)।

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

Answer 5

क्या कोई कारण यह अच्छा विचार नहीं है? क्या मुझे कुछ पता होना चाहिए?

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

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

एफडब्ल्यूआईडब्ल्यू, यह तय करने की कोशिश कर रहा है कि "दृढ़ता से टाइप किया गया" प्रोग्रामिंग प्रतिमान "कमजोर/गतिशील रूप से टाइप किए गए" प्रोग्रामिंग प्रतिमान से बेहतर है या नहीं। यह इस बात पर निर्भर करेगा कि आपको क्या करना है।

Answer 6

सॉफ़्टवेयर परिप्रेक्ष्य से GUID वैश्विक स्तर पर अद्वितीय रूप से बेहतर है। से

उद्धरण: Primary Keys: IDs versus GUIDs

एक GUID का उपयोग के रूप में एक पंक्ति पहचान मूल्य अधिक natural-- लगता है और निश्चित रूप से अधिक सही मायने में unique-- एक 32-बिट पूर्णांक से। डाटाबेस गुरु जो सेल्को seems to agree। GUID प्राथमिक कुंजी कई विकास परिदृश्यों जैसे प्रतिकृति के लिए एक प्राकृतिक फिट हैं, या जब आपको डेटाबेस के बाहर प्राथमिक कुंजी उत्पन्न करने की आवश्यकता होती है।

GUID पेशेवरों

• अनोखा हर मेज के पार, हर डेटाबेस, हर सर्वर
: लेकिन यह अभी भी पारंपरिक 4 बाइट पूर्णांक ID के बीच तालमेल और 16-बाइट GUIDs संतुलन का सवाल है
• विभिन्न डेटाबेस से रिकॉर्ड्स के आसान विलय की अनुमति देता है
• एकाधिक सर्वरों पर डेटाबेस के आसान वितरण की अनुमति देता है
• आप आईडी उत्पन्न कर सकते हैं कहीं भी, बजाय डेटाबेस के लिए roundtrip के लिए होने की
• अधिकांश प्रतिकृति परिदृश्यों GUID कॉलम की आवश्यकता होती है वैसे भी

GUID विपक्ष

• यह एक whopping 4 बार पारंपरिक 4 बाइट सूचकांक से भी बड़ा है मूल्य; इस गंभीर प्रदर्शन और भंडारण प्रभाव हो सकता है अगर आप सावधान नहीं कर रहे हैं
• डिबग करना जटिल जहां userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'
• उत्पन्न GUIDs सर्वश्रेष्ठ प्रदर्शन के लिए आंशिक रूप से अनुक्रमिक होना चाहिए (उदाहरण के लिए , newsequentialid() SQL 2005) पर और क्लस्टर अनुक्रमित