टेबल डिजाइन करते समय, मैंने एक कॉलम होने की आदत विकसित की है जो अद्वितीय है और मैं प्राथमिक कुंजी बनाता हूं। आवश्यकताओं के आधार पर इसे तीन तरीकों से हासिल किया जाता है:

पहचान पूर्णांक स्तंभ कि ऑटो वेतन वृद्धि।
विशिष्ट पहचानकर्ता (GUID)
एक छोटा वर्ण (x) या पूर्णांक (या अन्य अपेक्षाकृत छोटे संख्यात्मक प्रकार) स्तंभ जो पंक्ति पहचानकर्ता स्तंभ के रूप में काम कर सकता है

नंबर 3 का उपयोग काफी छोटे लुकअप के लिए किया जाएगा, ज्यादातर पढ़ने वाली तालिकाओं में एक अद्वितीय स्थैतिक लंबाई स्ट्रिंग कोड, या एक संख्यात्मक मान हो सकता है जैसे कि एक वर्ष या अन्य संख्या।

अधिकांश भाग के लिए, अन्य सभी तालिकाओं में या तो एक ऑटो-इंक्रीमेंटिंग पूर्णांक या विशिष्ट पहचानकर्ता प्राथमिक कुंजी होगी।

प्रश्न :-)

मैंने हाल ही में ऐसे डेटाबेस के साथ काम करना शुरू किया है जिनकी कोई सुसंगत पंक्ति पहचानकर्ता नहीं है और प्राथमिक कुंजी वर्तमान में विभिन्न स्तंभों में क्लस्टर की गई हैं। कुछ उदाहरण:

दिनांक / चरित्र
दिनांक / पूर्णांक
दिनांक / varchar
चार / nvarchar / nvarchar

क्या इसके लिए कोई वैध मामला है? मैंने हमेशा इन मामलों के लिए एक पहचान या विशिष्ट पहचानकर्ता कॉलम परिभाषित किया होगा।

इसके अलावा प्राथमिक कुंजी के बिना कई टेबल हैं। इसके लिए मान्य कारण, यदि कोई हो, तो क्या हैं?

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

एक तीसरा प्रश्न है जो मुझे जवाबों को समझने में मदद करने के लिए है: ऐसे मामलों में जहां यौगिक प्राथमिक कुंजी को समाहित करने के लिए कई स्तंभों का उपयोग किया जाता है, क्या इस पद्धति बनाम सरोगेट / कृत्रिम कुंजी का एक विशिष्ट लाभ है? मैं ज्यादातर प्रदर्शन, रखरखाव, प्रशासन, आदि के संबंध में सोच रहा हूं?

— लॉयड कॉटन
स्रोत

मैंने पाया डेटाबेस कौशल: एक साने दृष्टिकोण प्राथमिक कुंजी का चयन करने के लिए एक अच्छा पढ़ा है और मैं उल्लिखित अधिकांश बिंदुओं का पालन करता हूं।

— user2864740

254

मैं कुछ नियमों का पालन करता हूं:

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

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

— Logicalmind
स्रोत

3

मुझें यह पसंद है! क्या आपके पास अपने "नियमों" के आधार के लिए कोई दस्तावेज है? धन्यवाद!

— लॉयड कोट

4

नहीं, सिर्फ अनुभव। "छोटे" डेटाबेस से निपटने के दौरान यह सामान इतना मायने नहीं रखता। लेकिन जब आप बड़ी db के साथ सभी छोटी चीज़ों से निपटते हैं। जरा सोचिए कि अगर आपके पास टेक्स्ट या गाइड के इस्तेमाल की तुलना में इंट या लॉन्ग पीके की 1 बिलियन पंक्तियां हैं। बहुत बड़ा अंतर है!

— लॉजिकलमाइंड

44

जब आप एक आर्टिफिशियल कुंजी का उपयोग करते हैं, तो उस अद्वितीय सूचकांक को प्राकृतिक कुंजी पर रखने के लिए याद रखें (यदि कोई वास्तव में मौजूद है जो अक्सर ऐसा नहीं होता है)।

— HLGEM

3

@ लॉयड कॉटन: यहां नियम नंबर 1 के समर्थन में एक बड़ा डेटा इंजन प्रदाता कहता है: Skyfoundry.com/forum/topic/24 । इसने मुझे Int

— २०:१३

4

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

— एंड्रयू हिल

90

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

यूएस स्टेट्स: मैं टेक्सास के लिए State_id = 1 के बजाय State_code (टेक्सास आदि के लिए 'TX') जाऊंगा
कर्मचारी: मैं आमतौर पर एक आर्टिफिशियल कर्मचारी_आईडी बनाऊंगा, क्योंकि यह काम करने वाले किसी और चीज़ को खोजना मुश्किल है। SSN या समकक्ष काम कर सकते हैं, लेकिन नए जॉइनर जैसे मुद्दे हो सकते हैं जिन्होंने अभी तक SSN को आपूर्ति नहीं की है।
कर्मचारी वेतन इतिहास: (कर्मचारी_प्रकार, प्रारंभ_डेट)। मैं एक आर्टिफिशियल कर्मचारी_सालरी_हिस्ट्री_ड नहीं बनाऊंगा। यह किस बिंदु पर काम करेगा ( "मूर्खता की संगति के अलावा" )

जहां भी कृत्रिम कुंजी का उपयोग किया जाता है, आपको हमेशा प्राकृतिक कुंजियों पर अद्वितीय बाधाओं की घोषणा करनी चाहिए। उदाहरण के लिए, State_id का उपयोग करें यदि आप अवश्य करें, लेकिन तब आप State_code पर एक अद्वितीय बाधा घोषित करेंगे, अन्यथा आप अंततः इसके साथ समाप्त होना सुनिश्चित करते हैं:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

— टोनी एंड्रयूज
स्रोत

9

SQL सर्वर 2005/2008 के साथ कुछ मामलों में प्राकृतिक (पाठ) कुंजी एक इंट कुंजी की तुलना में तेज हो सकती है। मेरे पास एक 7-8 चरित्र के अनुकूल कोड वाला एक ऐप है जिसे हम प्राथमिक कुंजी के रूप में उपयोग करते हैं और यह एक इंटेरोगेट की तुलना में तेज (और अक्सर अधिक सुविधाजनक) था। हमें वैसे भी कोड की आवश्यकता थी ताकि हमारे पास एक मानव पठनीय / यादगार कोड हो सके जिसे हम अलग-अलग एप्लिकेशन इंस्टेंस के लिए संघर्ष के बिना सुरक्षित रूप से स्थानांतरित कर सकें (कई साइटें जो एक बड़ी साइट में एकत्र होती हैं)।

— लैम्बेक

1

+1 अच्छा जवाब। हालाँकि, मैं कार्मिक अधिकारी को एक कर्मचारी पहचानकर्ता का विश्वसनीय स्रोत होने का अधिकारी दूंगा अर्थात वास्तविक जीवन में कर्मचारियों की पुष्टि करने के लिए जिम्मेदार अधिकारी जो एसएसएन जैसे पहचानकर्ता का उपयोग करने की संभावना रखते हैं, संदर्भ लेते हैं, आदि कार्मिक विभाग पर भरोसा किया जाना चाहिए। कर्मचारी पहचानकर्ताओं का स्रोत, DBMS नहीं!

— onedaywhen

@ onedaywhen- मैं नहीं करूंगा। कार्मिक अधिकारी पर भरोसा रखें। लोग निकलते हैं, नए आते हैं और अलग-अलग विचार रखते हैं। उन्हें पहचानकर्ता तक पहुंच प्रदान करें जो उन्हें लगता है कि अद्वितीय है / वे उपयोग करना चाहते हैं, लेकिन आंतरिक रूप से db के लिए, dba को अपना निर्णय लेना चाहिए

— डेव पाइल

1

ध्यान दें कि हर देश में एसएसएन आवश्यक नहीं है। कम से कम ऑस्ट्रिया में, कई लोग एक ही नंबर साझा कर सकते हैं

— माज़ा

कुछ देशों में भी (मुझे लगता है कि अमेरिका में भी) वे वास्तव में एसएसएन को साझा नहीं करने की सलाह देते हैं।

— स्टिजेन डे विट

25

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

मान लें कि हमारे पास ये टेबल और कॉलम हैं:

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

इस मामले में कि अंतिम बिट का कोई मतलब नहीं है, Invoice.CompanyIdदो विदेशी कुंजियों का एक हिस्सा है, एक कोस्टीवेट टेबल और एक कोस्टीमेंट टेबल। प्राथमिक कुंजी (है InvoiceId , CompanyId )।

इस मॉडल में, यह पेंच-अप और एक संदर्भ के लिए संभव नहीं है CostElement एक कंपनी से और एक CostCentre एक और कंपनी से। यदि एक सरोगेट कुंजी का उपयोग कॉस्टइलमेंट और कॉस्टेक्शन टेबल्स पर किया गया था , तो यह होगा।

कम संभावना है, बेहतर पेंच।

— WW।
स्रोत

6

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

— सैमुअल डेनियलसन

24

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

मेरी प्राथमिक कुंजियाँ पृष्ठभूमि में डेटाबेस प्रोग्राम द्वारा नियंत्रित की जाती हैं और उपयोगकर्ता को उनके बारे में कभी भी जानकारी नहीं होती है।

— पॉल
स्रोत

1

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

— एलेक्स जोर्गेनसन

13

विभिन्न क्षेत्रों से अपनी प्राथमिक कुंजी बनाने में कोई समस्या नहीं है, यह एक प्राकृतिक कुंजी है ।

आप एक सरोगेट कुंजी बनाने के लिए एक पहचान स्तंभ (उम्मीदवार क्षेत्रों पर एक अद्वितीय सूचकांक के साथ जुड़े) का उपयोग कर सकते हैं ।

यह एक पुरानी चर्चा है। मैं ज्यादातर स्थितियों में सरोगेट कुंजी पसंद करता हूं।

लेकिन एक कुंजी की कमी के लिए कोई बहाना नहीं है।

पुन: संपादित करें

हाँ, इस बारे में बहुत विवाद है: डी

मैं प्राकृतिक कुंजियों पर कोई स्पष्ट लाभ नहीं देखता, इस तथ्य के अलावा कि वे प्राकृतिक पसंद हैं। आप हमेशा Name, SocialNumber में सोचेंगे - या ऐसा कुछ - जैसे idPerson ।

सरोगेट कुंजी उन कुछ समस्याओं का उत्तर है, जो प्राकृतिक कुंजी है (उदाहरण के लिए परिवर्तनों का प्रचार करना)।

जैसा कि आप सरोगेट की आदत डाल लेते हैं, यह अधिक स्वच्छ और प्रबंधनीय लगता है।

लेकिन अंत में, आपको पता चलेगा कि यह सिर्फ स्वाद की बात है - या मानसिकता -। प्राकृतिक कुंजी के साथ लोग "बेहतर सोचते हैं", और अन्य लोग नहीं करते हैं।

— DonOctavioDelFlores
स्रोत

13

प्राकृतिक कुंजियों के साथ लोग "बेहतर सोचते हैं"। मशीनें और डेटाबेस, नहीं।

— एफडीसीएस्टल

11

हर समय टेबल के पास एक प्राथमिक कुंजी होनी चाहिए। जब यह नहीं होता है यह एक AutoIncrement फ़ील्ड होना चाहिए था।

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

लिंक टेबल के बारे में कुछ एक टिप्पणी करते हैं , यह सही है, यह अपवाद है लेकिन अखंडता बनाए रखने के लिए फ़ील्ड फ़ील्ड FK होना चाहिए, और कुछ मामले हैं कि फ़ील्ड प्राथमिक कुंजी भी हो सकती हैं यदि लिंक में डुप्लिकेट अधिकृत नहीं हैं ... लेकिन एक में रखने के लिए सरल रूप क्योंकि प्रोग्रामिंग में अपवाद अक्सर होता है, आपके डेटा की अखंडता को बनाए रखने के लिए प्राथमिक कुंजी मौजूद होनी चाहिए।

— पैट्रिक डेसजार्डिन
स्रोत

मैं सहमत हूँ। और उस स्थिति में जहां बहुत सारा डेटा डाला जाना है, प्राथमिक कुंजी बाधा को दूर करें (या TSQL में INSERT IDENTITY का उपयोग करें) और इसे बाद में वापस रख दें :)

— एंड्रयू रोलिंग्स

1

कुछ अपवाद हैं: लिंक टेबल स्पष्ट रूप से

— annakata

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

— डेनिस सी 10

डेटा वेयरहाउस तथ्य तालिका से पीके को छोड़ना काफी आम है। Oracle में आप अल्पावधि में एक विशिष्ट पहचानकर्ता के रूप में ROWID छद्म चॉकलेट का संदर्भ दे सकते हैं (अर्थात इसे कहीं स्टोर न करें और इसे बदलने की उम्मीद न करें)

— David Aldridge

9

उन सभी अच्छे उत्तरों के अलावा, मैं सिर्फ एक अच्छा लेख साझा करना चाहता हूं जो मैंने अभी पढ़ा है, महान प्राथमिक-प्रमुख बहस ।

बस कुछ बिंदुओं को उद्धृत करने के लिए:

प्रत्येक तालिका के लिए प्राथमिक कुंजी चुनते समय डेवलपर को कुछ नियम लागू करने चाहिए:

प्राथमिक कुंजी को विशिष्ट रूप से प्रत्येक रिकॉर्ड की पहचान करनी चाहिए।
रिकॉर्ड का प्राथमिक-कुंजी मान शून्य नहीं हो सकता।
रिकॉर्ड बनाते समय प्राथमिक कुंजी-मान मौजूद होना चाहिए।
प्राथमिक कुंजी स्थिर रहना चाहिए - आप प्राथमिक-कुंजी फ़ील्ड (क्षेत्रों) को बदल नहीं सकते हैं।
प्राथमिक कुंजी कॉम्पैक्ट होनी चाहिए और सबसे कम संभव विशेषताओं को समाहित करना चाहिए।
प्राथमिक-कुंजी मान को बदला नहीं जा सकता।

प्राकृतिक कुंजी (प्रवृत्ति) नियमों को तोड़ती हैं। सरोगेट कुंजी नियमों का अनुपालन करती है। (आप उस लेख के माध्यम से बेहतर पढ़ते हैं, यह आपके समय के लायक है!)

— RayLuo
स्रोत

7

प्राथमिक कुंजी के बारे में क्या खास है?

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

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

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

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

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

यह कहने के बाद, मैं कई खराब डिज़ाइन किए गए डेटाबेस के लिए आभारी हूं जो आज व्यवसायों में मौजूद हैं (अर्थहीन-सरोगेट-कुंजी-डेटा-दूषित -१ एनएफ किन्नर), क्योंकि इसका मतलब है कि लोगों के लिए एक अंतहीन राशि है जो उचित डेटाबेस डिज़ाइन को समझते हैं । लेकिन दुखद पक्ष पर, यह कभी-कभी मुझे साइसेफस की तरह महसूस करता है, लेकिन मैंने शर्त लगाई कि उसके पास एक दुर्घटनाग्रस्त (दुर्घटना से पहले) 401k की एक बिल्ली थी। महत्वपूर्ण डेटाबेस डिजाइन प्रश्नों के लिए ब्लॉग और वेबसाइटों से दूर रहें। यदि आप डेटाबेस डिजाइन कर रहे हैं, तो CJ Date देखें। आप SQL सर्वर के लिए Celko को भी संदर्भित कर सकते हैं, लेकिन केवल तभी जब आप अपनी नाक को पकड़ते हैं। ओरेकल की ओर, संदर्भ टॉम Kyte।

— ल्यूक
स्रोत

1

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

— वज़

6

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

यदि सिर्फ डेटाइम सार्थक है, और इसे केवल अद्वितीय बनाने के लिए चार टैकल किया जाता है, तो आप बस एक पहचान क्षेत्र के साथ जा सकते हैं।

— जेम्स क्यूरन
स्रोत

9

आमतौर पर सबसे अच्छा? मेरे पास कोई वैज्ञानिक आधार नहीं है, लेकिन मैं लगभग सकारात्मक हूं ज्यादातर लोग प्राकृतिक पर एक सरोगेट कुंजी पसंद करते हैं। कई मामलों में कोई प्राकृतिक कुंजी नहीं है।

— जे.सी.

3

आपके डेटाबेस में किसी भी पंक्ति के लिए हमेशा एक प्राकृतिक कुंजी होनी चाहिए। वह "प्राकृतिक" कुंजी व्यवसाय की दुनिया में या आपकी तकनीकी प्रणाली से उत्पन्न हो सकती है, लेकिन यह हमेशा मौजूद होनी चाहिए।

— टॉम एच

2

यदि, आपकी दुनिया में, टेबल में एक पंक्ति को पहचानने का एकमात्र तरीका निर्धारित किया गया है, तो हाँ। बेशक, जब एक डिजाइनर पीके के लिए एक GUID बनाने का चयन करता है, तो यह आमतौर पर होता है क्योंकि उन्होंने वास्तविक प्राकृतिक कुंजी खोजने के लिए काम नहीं किया है, इसलिए उस मामले में GUID प्राकृतिक कुंजी नहीं है।

— टॉम एच

8

2. यदि आप प्राकृतिक दुनिया से अपनी कुंजी लेते हैं, तो प्राकृतिक दुनिया आपकी कुंजी को तोड़ने के लिए बदल जाएगी। यदि आप टेलीफोन नंबर का उपयोग करते हैं, तो आपको एक ही घर से दो उपयोगकर्ता मिलेंगे। यदि आप अंतिम नाम का उपयोग करते हैं, तो वे शादी कर लेते हैं। यदि आप SSN का उपयोग करते हैं, तो गोपनीयता कानून बदल जाएंगे और आपको उन्हें हटाने की आवश्यकता होगी।

— जेम्स ओआर

2

@ बैरी: आरई: # 2। यदि प्राकृतिक दुनिया बदलती है और जो आपकी प्राकृतिक कुंजी को बदलने का कारण बनती है, जिसका अर्थ है कि आपने एक प्राकृतिक कुंजी का चयन करके एक खराब काम किया है। परिभाषा के अनुसार, समय के साथ एक प्राकृतिक कुंजी नहीं बदलती है।

— टॉम एच

6

यहां मेरे अपने अंगूठे के नियम हैं जो मैंने 25+ वर्षों के विकास के अनुभव के बाद तय किए हैं।

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

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

हमेशा एक ही मूल्य प्राथमिक कुंजी होने से यूपीएसईआरटी बहुत सीधा प्रदर्शन करता है।

बहु-स्तंभ कुंजियों का समर्थन करने के लिए अतिरिक्त सूचकांकों का उपयोग करें जो आपके आवेदन में अर्थ रखते हैं।

— रोडनी पी। बारबाती
स्रोत

5

मेरे लिए प्राकृतिक बनाम कृत्रिम कुंजी इस बात का विषय है कि आप अपने डेटाबेस में कितने व्यावसायिक तर्क चाहते हैं। सामाजिक सुरक्षा संख्या (SSN) एक बेहतरीन उदाहरण है।

"मेरे डेटाबेस में प्रत्येक ग्राहक, और एक SSN होना चाहिए।" बाम, किया, इसे प्राथमिक कुंजी बनाएं और इसके साथ किया जाए। बस याद रखें कि जब आपका व्यवसाय नियम बदल जाता है तो आप जल जाते हैं।

व्यावसायिक नियमों को बदलने के साथ अपने अनुभव के कारण, मुझे स्वयं प्राकृतिक कुंजियाँ पसंद नहीं हैं। लेकिन अगर आपका यकीन है कि यह नहीं बदलेगा, यह कुछ महत्वपूर्ण जोड़ को रोक सकता है।

— डैन विलियम्स
स्रोत

8

और मैंने डेटा देखा है जहां एसएसएन अद्वितीय नहीं है, भले ही यह होना चाहिए। यदि आप अपने डेटा को किसी अन्य स्रोत से आयात करते हैं, तो प्राकृतिक कुंजियों से बहुत सावधान रहें!

— HLGEM

2

यदि आप पहचान की चोरी के अधीन हैं, तो आप अपना सामाजिक सुरक्षा नंबर बदल सकते हैं। चार और स्थितियां हैं जहां वे आपका नंबर बदल देंगे और वे ssa.gov साइट पर सूचीबद्ध होंगे।

— ज़्वी ट्वर्स्की

4

मुझे संदेह है कि मूल डेटा संरचना के डिजाइनर के लिए स्टीवन ए लोव के लुढ़का हुआ अखबार थेरेपी आवश्यक है।

एक तरफ के रूप में, एक प्राथमिक कुंजी के रूप में GUIDs एक प्रदर्शन हॉग हो सकता है। मैं इसकी सिफारिश नहीं करूंगा।

— एंड्रयू रोलिंग
स्रोत

2

कहने के लिए इसका प्रदर्शन हॉग एक समयपूर्व अनुकूलन है। कुछ मामलों में अपराध की आवश्यकता होती है (डिस्कनेक्ट किए गए ग्राहक, भविष्य की तालिका विलय, प्रतिकृति)

— जेसी।

2

"प्रीमेच्योर ऑप्टिमाइज़ेशन" SO (IMHO) पर एक अप्रयुक्त वाक्यांश है! हां, कुछ मामलों में GUID की आवश्यकता हो सकती है, लेकिन एंड्रयू यह इंगित करने के लिए सही है कि उन्हें डिफ़ॉल्ट डेटा प्रकार के रूप में उपयोग किया जाना चाहिए या नहीं।

— टोनी एंड्रयूज

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

— जे.सी.

या दोनों का उपयोग करें। अच्छी त्वरित चयन और जॉइन के लिए एक इंट / लॉन्ग बेस्ड प्राइमरी की है, और फिर एक गाइड फील्ड है। कम से कम, कि मैं क्या कर रहा हूँ। क्या यह गलत है? क्या मुझे ऐसा नहीं करना चाहिए? :)

— एंड्रयू रोलिंग

मैं दोनों कॉलम का उपयोग भी कर रहा हूं। लेकिन यह सुनिश्चित नहीं है कि यह गलत है या नहीं। क्या आपको यह @AndrewRollings मिला?

— Y --GÒ

3

आपको एक 'समग्र' या 'मिश्रित' प्राथमिक कुंजी का उपयोग करना चाहिए जिसमें कई फ़ील्ड शामिल हैं।

यह एक पूरी तरह से स्वीकार्य समाधान है, अधिक जानकारी के लिए यहां जाएं :)

— एडम
स्रोत

3

मैं भी हमेशा एक संख्यात्मक आईडी कॉलम का उपयोग करता हूं। Oracle में मैं संख्या (18,0) से अधिक वास्तविक कारण के लिए नंबर (18,0) का उपयोग करता हूं (या जो एक लंबे समय के बजाय एक इंट) है, शायद मैं बस कुछ अरब पंक्तियों को प्राप्त करने के बारे में कभी चिंता नहीं करना चाहता हूं db!

मैं बुनियादी ट्रैकिंग के लिए एक बनाया और संशोधित कॉलम (प्रकार टाइमस्टैम्प) भी शामिल करता हूं, जहां यह उपयोगी लगता है।

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

— JeeBee
स्रोत

2

मुझे यह भी बताना चाहिए कि मैं आईडी को लिंक / टेबल से नहीं जोड़ता, केवल डेटा वाले टेबल पर।

— JeeBee

3

मैं प्राकृतिक प्राथमिक कुंजी खोजता हूं और उनका उपयोग करता हूं जहां मैं कर सकता हूं।

यदि कोई प्राकृतिक कुंजी नहीं मिल सकती है, तो मैं एक INT ++ के लिए GUID पसंद करता हूं क्योंकि SQL सर्वर पेड़ों का उपयोग करता है, और यह हमेशा बुरा होता है कि पेड़ों में अंत में चाबियाँ जोड़ें।

टेबल पर जो कई-से-कई कपलिंग हैं मैं विदेशी कुंजियों की एक प्राथमिक प्राथमिक कुंजी का उपयोग करता हूं।

क्योंकि मैं SQL सर्वर का उपयोग करने के लिए पर्याप्त भाग्यशाली हूं, मैं प्रोफाइलर और क्वेरी विश्लेषक के साथ निष्पादन योजनाओं और आंकड़ों का अध्ययन कर सकता हूं और पता लगा सकता हूं कि मेरी चाबियाँ बहुत आसानी से कैसे प्रदर्शन कर रही हैं।

— Guge
स्रोत

क्या आपके पास इस कथन का समर्थन करने के लिए कोई दस्तावेज़ है: 'यदि कोई प्राकृतिक कुंजी नहीं मिल सकती है, तो मैं एक INT ++ के लिए GUID पसंद करता हूं क्योंकि SQL सर्वर पेड़ों का उपयोग करता है, और यह हमेशा बुरा होता है कि पेड़ों में अंत तक कुंजियाँ जोड़ें।' संदेह नहीं है, बस कुछ दस्तावेज़ीकरण संकलित करने की कोशिश कर रहा है।

— लॉयड कॉटन

1

@ लॉयड - खुशी है कि आप किसी ऐसी चीज में दिलचस्पी ले रहे हैं जो मुझे खुद बहुत आकर्षक लगती है। पर एक अच्छा प्रारंभिक बिंदु msdn.microsoft.com/en-us/library/ms177443(SQL.90).aspx

— Guge

2

मैं हमेशा एक ऑटोनम्बर या पहचान क्षेत्र का उपयोग करता हूं।

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

— मैट
स्रोत

6

किसी डेवलपर द्वारा प्राकृतिक कुंजी के खराब चयन का मतलब यह नहीं है कि प्राकृतिक कुंजी खराब हैं।

— टॉम एच

1

एक उपकरण का उपयोग करने के लिए कठिन है किसी तरह उस उपकरण के खिलाफ एक बिंदु नहीं है?

— सकीय

1

सभी तालिकाओं में एक प्राथमिक कुंजी होनी चाहिए । अन्यथा, आपके पास एक HEAP है - यह, कुछ स्थितियों में, हो सकता है कि आप क्या चाहते हैं (जब आप डेटा ब्रोकर को किसी अन्य डेटाबेस या उदाहरण के लिए टेबल पर ले जाते हैं तो भारी लोड डालें)।

पंक्तियों की कम मात्रा वाली तालिकाओं को देखने के लिए, आप 3 CHAR कोड का उपयोग प्राथमिक कुंजी के रूप में कर सकते हैं क्योंकि यह INT से कम जगह लेता है, लेकिन प्रदर्शन अंतर नगण्य है। इसके अलावा, मैं हमेशा एक INT का उपयोग करता हूं जब तक कि आपके पास एक संदर्भ तालिका नहीं होती है जो संभवत: संबद्ध तालिकाओं से विदेशी कुंजी से बना एक समग्र प्राथमिक कुंजी है।

— Coolcoder
स्रोत

1

यदि आप वास्तव में इस सदियों पुरानी बहस पर आगे और पीछे के माध्यम से पढ़ना चाहते हैं, तो स्टीवर्ड ओवरफ्लो पर "प्राकृतिक कुंजी" की खोज करें। आपको परिणामों के पृष्ठ वापस मिलने चाहिए।

— टॉम एच
स्रोत

1

GUIDs एक प्राथमिक कुंजी के रूप में इस्तेमाल किया जा सकता है, लेकिन आप इतना है कि यह अच्छा प्रदर्शन GUID का सही प्रकार बनाना होगा।

आपको COMB GUIDs जेनरेट करने होंगे। इसके बारे में एक अच्छा लेख और प्रदर्शन के आँकड़े प्राथमिक कुंजी के रूप में GUIDs की लागत है ।

इसके अलावा में COMB GUIDs के निर्माण पर कुछ कोड एसक्यूएल में है बनाम पहचान uniqueidentifier ( संग्रह ) ।

— डोनी वी।
स्रोत

5

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

— लॉजिकमाइंड 19

यदि आप ऊपर दिए गए लिंक पर जाते हैं, तो COMB Guids के उपयोग से प्रदर्शन में बहुत कम अंतर है।

— डॉनी वी।

0

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

— दान ब्लेयर
स्रोत

1

यह रणनीति अलग हो जाती है जब आपको वास्तविक दो तालिकाओं में शामिल होने के लिए 6 तालिकाओं को पार करना पड़ता है जिनकी आपको आवश्यकता होती है क्योंकि समग्र कुंजियों का प्रचार नहीं किया गया था। यह कई आवेषणों के लिए छोरों / श्रापकर्ताओं के उपयोग की आवश्यकता को भी समाप्त करता है जो एक बड़ा प्रदर्शन हॉग हो सकता है।

— टॉम एच

2

मैं कुछ नया सीखने के लिए बड़ा नहीं हूं। मैं एक उदाहरण देखना पसंद करूंगा कि आप क्या कह रहे हैं, इन धार्मिक तर्कों में थोड़ा तर्कसंगत तथ्य को शामिल करना उपयोगी होगा।

— दान ब्लेयर

0

मैं प्राकृतिक कुंजी के लिए अपनी प्राथमिकता के बारे में सामने रहूंगा - जहां संभव हो, उनका उपयोग करें, क्योंकि वे डेटाबेस प्रशासन के आपके जीवन को बहुत आसान बना देंगे। मैंने अपनी कंपनी में एक मानक स्थापित किया है जिसमें सभी तालिकाओं में निम्नलिखित कॉलम हैं:

पंक्ति आईडी (GUID)
निर्माता (स्ट्रिंग; वर्तमान उपयोगकर्ता के नाम का डिफ़ॉल्ट है ( SUSER_SNAME()T-SQL में))
बनाया गया (दिनांक समय)
समय-चिह्न

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

इस बीच, वास्तविक पीके, यदि संभव हो तो, एक प्राकृतिक कुंजी है। मेरे आंतरिक नियम कुछ इस प्रकार हैं:

लोग - सरोगेट कुंजी का उपयोग करते हैं, जैसे INT। यदि यह आंतरिक है, तो सक्रिय निर्देशिका उपयोगकर्ता GUID एक स्वीकार्य विकल्प है
लुकअप टेबल (जैसे स्टेटसकोड) - एक छोटे CHAR कोड का उपयोग करें; INT की तुलना में इसे याद रखना आसान है, और कई मामलों में पेपर फॉर्म और उपयोगकर्ता इसका उपयोग संक्षिप्तता के लिए भी करेंगे (उदाहरण के लिए "एक्सपायर्ड" के लिए स्टेटस = "E", "स्वीकृत" के लिए "A", "नो एस्बेस्टस" के लिए "NADIS")। नमूने में ")
लिंकिंग टेबल - FKs का संयोजन (जैसे EventId, AttendeeId)

तो आदर्श रूप से आप एक प्राकृतिक, मानव-पठनीय और यादगार पीके, और एक ओआरएम-फ्रेंडली वन-आईडी-प्रति-टेबलआईडी के साथ समाप्त होते हैं।

कैविएट: मेरे द्वारा बनाए गए डेटाबेस को लाखों या अरबों के बजाय 100,000 के रिकॉर्ड तक बनाए रखा जाता है, इसलिए यदि आपके पास बड़ी प्रणालियों का अनुभव है जो मेरी सलाह को ध्यान में रखते हुए, मुझे अनदेखा करने के लिए स्वतंत्र महसूस करते हैं!

— कीथ विलियम्स
स्रोत

1

क्या आप कोई मजबूत प्राकृतिक कुंजी के साथ तालिकाओं के लिए दोनों GUID और INT एसके बनाने का सुझाव दे रहे हैं ?

आपके पास नहीं है, लेकिन लाभ हैं: ए) यदि आपको इसकी आवश्यकता है, तो यह प्रतिकृति को आसान बनाता है, बी) ओआरएम के साथ काम करते समय, आप इसे सहेजने से पहले कोड में अपनी वस्तु के लिए एक अद्वितीय आईडी असाइन कर सकते हैं (जो आपके लिए उपयोगी है) अपनी वस्तु पर बहुत सारे संपादन करने होंगे, शायद बचत करने से पहले एक सत्र कैश में सहेजना)। इस उदाहरण में कुंजी INT है; GUID सिर्फ एक बोनस है।

— कीथ विलियम्स

तालिकाओं में प्राथमिक कुंजी के लिए सबसे अच्छा अभ्यास क्या है?

प्रश्न :-)

प्राथमिक कुंजी के बारे में क्या खास है?