174

बंद हो गया । यह प्रश्न राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

6 साल पहले बंद हुआ ।

इस प्रश्न को सुधारें

यहां हम फिर से जाते हैं, पुराना तर्क अभी भी उठता है ...

क्या हमारे पास प्राथमिक कुंजी के रूप में बेहतर व्यवसाय कुंजी होगी, या हमारे पास व्यापार कुंजी क्षेत्र पर एक अद्वितीय बाधा के साथ एक सरोगेट आईडी (यानी एक SQL सर्वर पहचान) होगा?

कृपया, अपने सिद्धांत का समर्थन करने के लिए उदाहरण या प्रमाण प्रदान करें।

— मैरिकिको कोराज़ी
स्रोत

24

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

— EricE

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

— कोड

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

— मारियो

97

दोनों। अपना केक लो और खाओ।

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

यदि आप एक सरोगेट कुंजी का उपयोग करते हैं, तो आप अभी भी व्यावसायिक नियमों के अनुसार विशिष्टता सुनिश्चित करने के लिए एक व्यावसायिक कुंजी चाहते हैं।

— टेड
स्रोत

7

यदि आपके पास कई "उम्मीदवार" कुंजियाँ (फ़ील्ड या समान आकार के फ़ील्ड हैं जो पूरी तरह से रिक्त नहीं हैं) तो आप बॉयस-कोड्ड नॉर्मल फॉर्म के उल्लंघन की संभावना है। बीसीएनएफ 3 एनएफ से परे है, इसलिए बहुत से लोग इसके बारे में चिंता नहीं करते हैं। हालाँकि, ऐसी स्थितियाँ हैं, जहाँ बीसीएनएफ का होना बहुत मददगार है।

— एलन

2

माना। असली सवाल यह होना चाहिए: क्या मुझे अपनी मेज पर एक अद्वितीय सरोगेट कुंजी जोड़ना चाहिए? एक पूरी तरह से अन्य प्रश्न यह है कि तार्किक प्राथमिक कुंजी के लिए क्या उपयोग किया जाए। वे दोनों अनिवार्य रूप से सिर्फ गैर-अशक्त अद्वितीय सूचकांक अवरोध हैं।

— dkretz

1

"हर समस्या को दूसरे स्तर के अप्रत्यक्ष रूप से हल किया जाता है" ... सरोगेट कुंजी बस इतना ही है: एक अन्य अप्रत्यक्ष स्तर

— स्टीव श्नेप

5

मुझे यह अजीब लगता है कि कई टिप्पणियां यह दावा करती हैं कि कोई व्यक्ति सरोगेट कुंजी के बिना संबंध स्थापित नहीं कर सकता है। कई मामलों में, सरोगेट कुंजी बहुत ही कम है। क्यों कुछ ऐसा जोड़ा जाता है जो कोई मूल्य नहीं लाता है, लेकिन तकनीकी ऋण जोड़ता है (और कुछ मामलों में, अन्यथा एक अद्वितीय परिणाम अचानक गैर-अद्वितीय हो जाता है)।

— विल् मूर III

2

यह नॉट अनलकी बाधा से अधिक है। प्राथमिक कुंजी का उपयोग एक संकुल सूचकांक के रूप में किया जाता है जो आपके डेटा के भौतिक क्रम को निर्धारित करता है। सामान्य तौर पर, इंटेगर को संतुलित करना आसान है क्योंकि यह क्रमिक रूप से वृद्धि करता है और आपका डेटा डिस्क पर ईओएफ के लिए संलग्न होगा। यदि आप पाठ या GUID (UUID) जैसे कम अनुक्रमिक डेटा का उपयोग करते हैं, तो सूचकांक को संतुलित करने के लिए बहुत अधिक डिस्क IO और प्रयास होंगे, मुझे लगता है कि यह बड़े अंतर की तरह है

— जिन

124

सरोगेट कुंजी का उपयोग करने के कुछ कारण:

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

— जे चरवाहा
स्रोत

2

अब, सरोगेट कुंजी और प्राकृतिक कुंजी के बारे में बहुत कुछ पढ़ने के बाद, मुझे लगता है कि सरोगेट कुंजी का उपयोग करना बेहतर है। लेकिन, मेरे डेटाबेस में, प्राकृतिक कुंजियाँ (एक NVARCHAR (20)) अद्वितीय होनी चाहिए। मुझे यह समझ में नहीं आता है कि अगर मैं किसी भी मूल्य को दोहराने के लिए उस कॉलम पर हर डेटा की जांच करने की आवश्यकता है, तो मैं और अधिक गति कैसे प्राप्त कर सकता हूं (प्रत्येक नॉट UNIQUE बाधा का उपयोग करके)।

— वैनफैनलाइन

70

ऐसा प्रतीत होता है कि किसी ने अभी तक गैर-सरोगेट के समर्थन में कुछ भी नहीं कहा है (मैं "प्राकृतिक" कहने में संकोच करता हूं) चाबियाँ। तो यहाँ जाता है ...

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

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

विरुद्ध:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

जब तक किसी को गंभीरता से नहीं लगता कि निम्नलिखित एक अच्छा विचार है ?:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"लेकिन" कोई कहेगा, "क्या होता है जब MYPROJECT या VALID या HR के लिए कोड बदलता है?" जिस पर मेरा जवाब होगा: "आपको इसे बदलने की आवश्यकता क्यों होगी ?" ये इस अर्थ में "प्राकृतिक" कुंजियाँ नहीं हैं कि कुछ बाहरी निकाय इस तरह से कानून बनाने जा रहे हैं कि 'VALID' को 'GOOD' के रूप में फिर से कोडित किया जाए। "प्राकृतिक" कुंजी का केवल एक छोटा प्रतिशत वास्तव में उस श्रेणी में आता है - एसएसएन और ज़िप कोड सामान्य उदाहरण हैं। मैं निश्चित रूप से व्यक्ति, पता - जैसे तालिकाओं के लिए एक अर्थहीन संख्यात्मक कुंजी का उपयोग करूंगा, लेकिन सब कुछ के लिए नहीं , जो किसी कारण से यहां ज्यादातर लोग वकालत करते प्रतीत होते हैं।

यह भी देखें: एक और सवाल का मेरा जवाब

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

14

-1 प्राथमिक कुंजी के रूप में प्राकृतिक कुंजी में समस्या है कि हर बच्चे की तालिका के लिए आपको माता-पिता की कुंजी को जोड़ना होगा जो एक से अधिक फ़ील्ड (केवल एक के बजाय जो कि सरोगेट कुंजी का मामला है) और बच्चे को भी बनाया जा सकता है चाभी। तो कल्पना कीजिए कि TABLEA से शुरू होने के बाद रिश्ता क्या है। 1-0: *: TABLEA PK: ID_A TABLEB PK: ID_A ID_B TABLEC PK: ID_A ID_B ID_C TABLED PK: ID_A ID_B ID_C ID_D ID_D। समस्या देखें? पैरेंट कुंजी को बच्चों की तालिकाओं में प्रचारित किया जाता है। यदि TABLEA की प्राथमिक कुंजी बदल जाती है तो क्या होगा? अब आपको सभी बच्चे टेबल पीके को भी रिफलेक्टर करना होगा।

— अल्फ्रेडो ओसोरियो

9

@ ऑल्फ्रेडो: हाँ, वहाँ एक व्यापार बंद है। हालाँकि, मेरे 20+ वर्षों के अनुभव में मैंने शायद ही कभी किसी तालिका के PK परिवर्तन की परिभाषा देखी हो। यदि यह नियमित रूप से होता है तो मैं शायद प्राकृतिक कुंजियों से भी बचूंगा। वास्तव में, अत्यंत दुर्लभ अवसरों पर ऐसा होता है कि मैं विस्तारित प्रभाव के हिट लेने के लिए तैयार हूं।

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

10

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

— TTT

8

@ टीटीटी: तब डिजाइन की शुरुआत कमजोर थी। फिर, यह वह जगह है जहां पुरुष लड़कों से अलग होते हैं: प्राकृतिक कुंजी का उपयोग कब करना है, और सरोगेट का उपयोग कब करना है, इसका सही विकल्प बनाना। आप तय करते हैं कि प्रति-टेबल के आधार पर, सामान्य हठधर्मिता के रूप में नहीं।

— डैनमैन

7

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

— एसक्यूएल पुलिस

31

सरोगेट कुंजी को बदलने का एक कारण होगा। मैं प्राकृतिक कुंजियों के बारे में ऐसा नहीं कह सकता। अंतिम नाम, ईमेल, आईएसबीएन nubmers - वे सभी एक दिन बदल सकते हैं।

— Rimantas
स्रोत

31

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

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

थिंक कंपनियां: आप एक खुश मर्किन कंपनी हैं जो मर्किया में अन्य कंपनियों के साथ कारोबार कर रही हैं। आप कंपनी के नाम को प्राथमिक कुंजी के रूप में उपयोग नहीं करने के लिए पर्याप्त चतुर हैं, इसलिए आप 10 अल्फ़ान्यूमेरिक वर्णों की संपूर्णता में मर्किया की सरकार की अद्वितीय कंपनी आईडी का उपयोग करते हैं। तब मर्किया ने कंपनी आईडी बदल दी क्योंकि उन्हें लगा कि यह एक अच्छा विचार होगा। यह ठीक है, आप अपने db इंजन के कैस्केड अद्यतन सुविधा का उपयोग करते हैं, एक बदलाव के लिए जो आपको पहले स्थान पर शामिल नहीं करना चाहिए। बाद में, आपका व्यवसाय फैलता है, और अब आप फ्रीडोनिया में एक कंपनी के साथ काम करते हैं। फ्रीडोनियन कंपनी आईडी 16 अक्षरों तक की होती है। आपको कंपनी आईडी प्राथमिक कुंजी (आदेशों, मुद्दों, मनीट्रांसफर आदि में भी विदेशी कुंजी फ़ील्ड) को बढ़ाने की आवश्यकता है, प्राथमिक कुंजी में एक विदेशी क्षेत्र (विदेशी कुंजियों में भी) को जोड़ना। आउच! फ्रीडोनिया में गृहयुद्ध, यह ' तीन देशों में विभाजित है। आपके सहयोगी का देश का नाम बदलकर नया होना चाहिए; बचाव के लिए अद्यतन कैस्केड। BTW, आपकी प्राथमिक कुंजी क्या है? (कंट्री, कंपनीआईडी) या (कंपनीआईडी, कंट्री)? उत्तरार्द्ध जुड़ने में मदद करता है, पूर्व एक और सूचकांक से बचता है (या शायद बहुत से, आपको अपने आदेश को देश द्वारा भी समूहीकृत करना चाहिए)।

ये सभी सबूत नहीं हैं, लेकिन एक संकेत है कि सरोगेट कुंजी विशिष्ट रूप से सभी कार्यों के लिए एक पंक्ति की पहचान करने के लिए, जिसमें शामिल होने के लिए एक व्यावसायिक कुंजी भी बेहतर है।

— tzot
स्रोत

आप सबसे अच्छे दिखने वाले उपयोगकर्ता नाम के साथ सभी इंटर्नेट जीतते हैं!

— आईन होल्डर

1

यह बहुत ही कम है कि एक गिरावट है: "मैं इस बात से सहमत नहीं हूं।"

— जेकलूम

5

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

— tzot

1

यदि कोई यह सोचता है कि आपका उत्तर गलत है, तो वह (/ वह) भी यह सोचेगा कि यह प्रश्नकर्ता को गलत दिशा (सही दिशा के विपरीत) की ओर ले जाता है, और इसलिए आपके उत्तर को "अनहेल्दी" से भी बदतर होने का न्याय करेगा, उसके (/ उसके) मन में एक नीचा दिखा।

— एरविन स्मौट

1

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

— शमूएल डेनियलसन

25

मुझे सामान्य तौर पर सरोगेट कीज़ से नफरत है। उनका उपयोग केवल तब किया जाना चाहिए जब कोई गुणवत्ता प्राकृतिक कुंजी उपलब्ध न हो। जब आप इसके बारे में सोचते हैं, तो यह सोचना बेतुका है कि आपके टेबल पर अर्थहीन डेटा जोड़ने से चीजें बेहतर हो सकती हैं।

यहाँ मेरे कारण हैं:

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

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

— केन
स्रोत

7

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

— वाल्टर मिटी

26

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

— फाल्कन

6

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

— एरिक

3

प्राकृतिक कुंजी के खिलाफ एक और कारण (उदाहरण: परमाणु संख्या, VINs, आदि), व्यापार तर्क बदल सकता है जो डेटा के प्रकार को बढ़ाता है। उदाहरण के लिए - इससे पहले: परमाणुओं के ट्रैकिंग शुल्क, बाद: परमाणुओं और यौगिकों के ट्रैकिंग शुल्क। पहले: लोड क्षमता के लिए मोटर वाहन पर नज़र रखना। के बाद: भार वहन क्षमता के लिए विमानों, नावों, बाइक और लोगों को जोड़ना।

— forforf

3

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

— कोड

18

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

जैसा कि ऐसा लगता है कि कई लोग सरोगेट कुंजी को प्लेग के रूप में लगभग सही समाधान और प्राकृतिक कुंजी के रूप में पेश करते हैं, मैं दूसरे दृष्टिकोण के तर्कों पर ध्यान केंद्रित करूंगा:

सरोगेट चाबियों का नुकसान

सरोगेट कुंजी हैं:

प्रदर्शन समस्याओं का स्रोत:
- वे आमतौर पर ऑटो-इंक्रीम्ड कॉलम का उपयोग करके लागू किए जाते हैं, जिसका अर्थ है:
  - हर बार जब आप नई आईडी प्राप्त करना चाहते हैं तो डेटाबेस के लिए एक राउंड ट्रिप
  - यदि एक दिन आपको अपने डेटा को एक स्कीमा से दूसरे में स्थानांतरित करने की आवश्यकता होती है (यह कम से कम मेरी कंपनी में काफी नियमित रूप से होता है) तो आप ईडी टकराव की समस्याओं का सामना कर सकते हैं। और हां मुझे पता है कि आप यूयूआईडी का उपयोग कर सकते हैं, लेकिन उन आखिरी के लिए 32 हेक्साडेसिमल अंकों की आवश्यकता होती है! (यदि आप डेटाबेस आकार के बारे में परवाह करते हैं तो यह एक मुद्दा हो सकता है)।
  - यदि आप अपने सभी सरोगेट कुंजी के लिए एक अनुक्रम का उपयोग कर रहे हैं - तो निश्चित रूप से - आप अपने डेटाबेस पर विवाद के साथ समाप्त हो जाएंगे।
प्रवण त्रुटि। एक अनुक्रम में एक max_value सीमा होती है - एक डेवलपर के रूप में - आपको निम्नलिखित बिंदुओं पर ध्यान देना होगा:
- आपको अपने अनुक्रम (जब अधिकतम मूल्य तक पहुँच जाता है, तो यह 1,2, ... पर वापस चला जाता है) पर चलना चाहिए।
- यदि आप अनुक्रम को अपने डेटा के एक आदेश (समय के साथ) के रूप में उपयोग कर रहे हैं, तो आपको साइकिल चलाने के मामले को संभालना होगा (Id 1 वाला कॉलम, Id max-value - 1) के साथ पंक्ति की तुलना में नया हो सकता है।
- सुनिश्चित करें कि आपका कोड (और यहां तक कि आपके क्लाइंट इंटरफेस जो कि आंतरिक आईडी के रूप में नहीं होना चाहिए) 32b / 64b पूर्णांकों का समर्थन करता है जो आपने अपने अनुक्रम मानों को संग्रहीत करने के लिए उपयोग किया था।
वे गैर डुप्लिकेट किए गए डेटा की गारंटी नहीं देते हैं। आपके पास हमेशा समान स्तंभ मानों के साथ 2 पंक्तियाँ हो सकती हैं, लेकिन एक भिन्न उत्पन्न मान के साथ। मेरे लिए यह एक डेटाबेस डिजाइन बिंदु से सरोगेट कुंजी की समस्या है।
विकिपीडिया में अधिक ...

प्राकृतिक कुंजियों पर मिथक

समग्र कुंजियाँ सरोगेट कुंजी की तुलना में कम अक्षम हैं। नहीं! यह प्रयुक्त डेटाबेस इंजन पर निर्भर करता है:
- आकाशवाणी
- माई एसक्यूएल
प्राकृतिक कुंजी वास्तविक जीवन में मौजूद नहीं है। क्षमा करें, लेकिन वे मौजूद हैं! विमानन उद्योग में, उदाहरण के लिए, एक दिए गए अनुसूचित उड़ान (एयरलाइन, प्रस्थानडेट, फ्लाइटनंबर, ऑपरेशनलसफिक्स) के बारे में निम्नलिखित टपल हमेशा अद्वितीय होगी । अधिक आम तौर पर, जब व्यापार डेटा का एक सेट किसी दिए गए मानक द्वारा अद्वितीय होने की गारंटी है तो डेटा का यह सेट एक [अच्छा] प्राकृतिक कुंजी उम्मीदवार है।
प्राकृतिक कुंजी बच्चे तालिकाओं के "स्कीमा को प्रदूषित करते हैं"। मेरे लिए यह एक वास्तविक समस्या से अधिक एक भावना है। 2 बाइट्स की 4-कॉलम प्राथमिक-कुंजी होने से प्रत्येक 11 बाइट्स के एकल कॉलम से अधिक कुशल हो सकता है। इसके अलावा, 4 कॉलम का उपयोग चाइल्ड टेबल को सीधे करने के लिए किया जा सकता है (पेरेंट टेबल में शामिल हुए बिना 4 कॉलम को एक क्लॉज में उपयोग करके)।

निष्कर्ष

प्राकृतिक कुंजियों का उपयोग करें जब ऐसा करना प्रासंगिक हो और सरोगेट कुंजी का उपयोग करें जब उनका उपयोग करना बेहतर हो।

आशा है कि यह किसी की मदद की!

— mwnsiri
स्रोत

3

क्या होता है जब अनुसूचित उड़ान के प्रस्थान को फिर से शेड्यूल किया जाता है? क्या आपको सभी संबंधित संस्थाओं को ट्रैक करना है और कुंजियों को हटाना है, या क्या आप वास्तव में संबंधित संस्थाओं की सभी कुंजियों को अपडेट करते हैं? या आप एक सरल, एकवचन तालिका (संभवतः 3NF भी नहीं) के साथ काम कर रहे हैं?

— कोड

एक्सेलेंट पॉइंट @ कोड 4 लाइफ

— 11:15 बजे

@ code4life: यही वह जगह है जहां ऑपरेशनलसफिक्स कूदता है। उसी उड़ान को बनाए रखने के लिए ताकि हम ग्राहक भ्रम से बचें, हम उदाहरण के लिए सिर्फ एक प्रत्यय (यानी 'डी') जोड़ते हैं।

— मवनेश्वर गिरी

"आपके पास हमेशा एक ही स्तंभ मान के साथ 2 पंक्तियाँ हो सकती हैं लेकिन एक अलग जनरेट किए गए मान के साथ" इसलिए बस अपने स्तंभों पर एक विशिष्ट या समग्र अद्वितीय बाधा डालें।

— wha7ever

15

Alway एक कुंजी का उपयोग करता है जिसका कोई व्यावसायिक अर्थ नहीं है। यह सिर्फ अच्छा अभ्यास है।

संपादित करें: मैं ऑनलाइन इसके लिए एक लिंक खोजने की कोशिश कर रहा था, लेकिन मैं नहीं कर सका। हालाँकि, 'पैटर्न ऑफ़ एंटरप्राइज आर्किटेक्चर' [फाउलर] में इस बात की अच्छी व्याख्या है कि आपको कुंजी के अलावा किसी भी अन्य चीज़ का उपयोग क्यों नहीं करना चाहिए, जिसमें कुंजी के अलावा कोई अर्थ नहीं है। यह इस तथ्य से उबलता है कि इसमें एक नौकरी और एक नौकरी होनी चाहिए।

— इयान होल्डर
स्रोत

22

मार्टिन फाउलर कई चीजें हो सकती हैं, लेकिन वे डेटाबेस डिजाइन पर एक अधिकार नहीं हैं।

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

मुझे लगता है कि निष्कर्ष पर पहुंचने से पहले आपको कुछ तर्क प्रदान करने चाहिए।

— Arne Evertsson

4

@ArneEvertsoon इसका कारण है। 'यह इस तथ्य से उबता है कि इसमें एक नौकरी और एक नौकरी होनी चाहिए।' एकल जिम्मेदारी।

— इलेन होल्डर

10

यदि आप अपने डेटा वर्गों को संभालने / उत्पन्न करने के लिए ORM टूल का उपयोग करने की योजना बनाते हैं, तो सरोगेट कुंजी काफी उपयोगी है। जबकि आप कुछ अधिक उन्नत मैपर्स (पढ़ें: हाइबरनेट) के साथ मिश्रित कुंजियों का उपयोग कर सकते हैं, यह आपके कोड में कुछ जटिलता जोड़ता है।

(बेशक, डेटाबेस शुद्धतावादियों का तर्क है कि यहां तक कि एक सरोगेट कुंजी की धारणा एक घृणा है।)

मैं उपयुक्त होने पर सरोगेट कुंजी के लिए uids का उपयोग करने का प्रशंसक हूं। उनके साथ प्रमुख जीत यह है कि आप अग्रिम में कुंजी जानते हैं जैसे कि आप पहले से निर्धारित आईडी के साथ एक वर्ग का एक उदाहरण बना सकते हैं और अद्वितीय होने की गारंटी दे सकते हैं, जबकि, कहते हैं, एक पूर्णांक कुंजी आपको 0 या डिफ़ॉल्ट करने की आवश्यकता होगी। जब आप सेव / अपडेट करते हैं तो 1 और एक उचित मूल्य पर अपडेट करें।

यूआईडी को देखने और गति में शामिल होने के मामले में दंड है, हालांकि यह प्रश्न में आवेदन पर निर्भर करता है कि क्या वे वांछनीय हैं।

— डेरेक लॉनलेस
स्रोत

6

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

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

— मार्क एम्बलिंग
स्रोत

1

दुर्भाग्य से कारों में एक प्राकृतिक कुंजी होती है जो बदलती नहीं है: VIN (कम से कम अमेरिका में ...)

— jcollum

@jcollum हाँ ठीक है, यह एक उचित बिंदु है। मेरी राय अभी भी हालांकि खड़ी है, मेरा उदाहरण जरूरी नहीं कि जितना अच्छा हो सकता था।

— मार्क एम्ब्लिंग

2

भाषाओं की एक सूची एक प्राकृतिक कुंजी के लिए एक उदाहरण होगी, जब आप इसे आईएसओ कोड पर आधारित करेंगे। इसलिए यदि आप तब एक निश्चित भाषा में तालिका से सामग्री लोड करना चाहते थे, तो आपको तालिका में शामिल होने की आवश्यकता नहीं होगी languagesक्योंकि भाषा कोड (आईडी) पहले से ही textsतालिका में है।

— डैनमैन

@ डनमैन मुझे वहां आपसे सहमत होना है। हमेशा कुछ उदाहरण होने जा रहे हैं जो एक प्राकृतिक कुंजी के साथ बेहतर काम करते हैं। नियम या सामान्य दृष्टिकोण कभी भी पूर्ण नहीं होते हैं, और यह एक उदाहरण है कि मैं आपके दृष्टिकोण के साथ 100% जाऊंगा :-)

— मार्क एम्ब्लिंग

5

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

फिर, आवश्यकतानुसार, अपने व्यापार की कुंजियों को अनन्य कंट्रास्ट या इंडेक्स के रूप में स्टैक करें। यह आपको डेटा अखंडता बरकरार रखेगा।

व्यावसायिक तर्क / प्राकृतिक कुंजियाँ बदल सकती हैं, लेकिन तालिका की फ़िसिकल कुंजी को कभी भी नहीं बदलना चाहिए।

— user7658
स्रोत

4

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

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

— सैंटियागो सीफास
स्रोत

2

सरोगेट कुंजी तब उपयोगी हो सकती है जब व्यावसायिक जानकारी बदल सकती है या समान हो सकती है। देश भर में व्यवसाय के नाम अद्वितीय नहीं हैं। मान लीजिए कि आप स्मिथ इलेक्ट्रॉनिक्स के दो व्यवसायों से निपटते हैं, एक कंसास में और एक मिशिगन में। आप उन्हें पते से अलग कर सकते हैं, लेकिन वह बदल जाएगा। यहां तक कि राज्य भी बदल सकता है; क्या होगा अगर कैनसस सिटी के स्मिथ इलेक्ट्रॉनिक्स, कैनसस नदी को कैनसस सिटी, मिसौरी में स्थानांतरित कर दें? इन व्यवसायों को प्राकृतिक कुंजी जानकारी के साथ अलग रखने का कोई स्पष्ट तरीका नहीं है, इसलिए एक सरोगेट कुंजी बहुत उपयोगी है।

एक आईएसबीएन नंबर की तरह सरोगेट कुंजी के बारे में सोचो। आमतौर पर, आप शीर्षक और लेखक द्वारा एक पुस्तक की पहचान करते हैं। हालाँकि, मुझे HP Willmott द्वारा "पर्ल हार्बर" नाम की दो किताबें मिली हैं, और वे निश्चित रूप से अलग-अलग किताबें हैं, न कि सिर्फ अलग-अलग संस्करण। इस तरह के एक मामले में, मैं किताबों के लुक, या पहले के बनाम बाद में का उल्लेख कर सकता था, लेकिन यह ठीक उसी तरह है जैसे मेरे पास वापस गिरने के लिए आईएसबीएन है।

— डेविड थॉर्नले
स्रोत

1

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

— क्रिस्टोफर कैशेल

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

— डेविड थॉर्नले

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

— थॉमस

2

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

— थॉमस

तकनीकी रूप से, निगम राज्यों के बीच नहीं जा सकते हैं; क्या होता है कि नए राज्य में एक नया निगम बनाया जाता है और संपत्ति हस्तांतरित की जाती है। जो डेटाबेस की जानकारी के लिए भी काम करता है।

— वारेन ड्यू

2

एक अनुस्मारक के रूप में यादृच्छिक सरोगेट कुंजी यानी GUYs जो XY8D7-DFD8S को पढ़ते हैं, उन पर क्लस्टर सूचकांकों को रखना अच्छा नहीं है, क्योंकि उनके पास SQL सर्वर में इन डेटा को भौतिक रूप से क्रमबद्ध करने की क्षमता नहीं है। इसके बजाय आपको इन आंकड़ों पर अद्वितीय सूचकांकों को रखना चाहिए, हालांकि यह मुख्य तालिका संचालन के लिए बस SQL प्रोफाइलर को चलाने के लिए भी फायदेमंद हो सकता है और फिर उन डेटा को डेटाबेस इंजन ट्यूनिंग सलाहकार में रख सकता है।

देखें धागा @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cn13129be

— ब्रायन हंस
स्रोत

मुझे पूरा यकीन है कि SQL सर्वर GUIDs को सॉर्ट कर सकता है ।

— माइकल ग्रीन

यह सही नहीं है, जबकि वे GUID का मूल्यांकन कर सकते हैं, जिसके परिणामस्वरूप एक मानव के लिए निरर्थक नहीं है। stackoverflow.com/questions/7810602/…

— ब्रायन स्वान

1

एक सच्चा कथन, लेकिन "SQL सर्वर में शारीरिक रूप से इन्हें छांटने की क्षमता नहीं है।"

— माइकल ग्रीन

2

केस 1: आपका टेबल लुकअप टेबल है जिसमें 50 से कम प्रकार (आवेषण) हैं

व्यवसाय / प्राकृतिक कुंजियों का उपयोग करें । उदाहरण के लिए:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

केस 2: आपकी तालिका एक है तालिका है जिसमें हजारों आवेषण हैं

सरोगेट / ऑटोइनक्रीमेंट कुंजियों का उपयोग करें । उदाहरण के लिए:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

पहले मामले में:

आप तालिका JOB में शामिल होने के उपयोग के बिना तालिका PEOPLE में सभी प्रोग्रामर का चयन कर सकते हैं, लेकिन बस इसके साथ: "चयन करें * लोगों से जहां JOBCODE = 'PRG'"

दूसरे मामले में:

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

— स्टेफानोस कारगास
स्रोत

2

यह उन मामलों में से एक है जहां एक सरोगेट कुंजी हमेशा बहुत मायने रखती है। ऐसे मामले हैं जहां आप या तो चुनते हैं कि डेटाबेस के लिए सबसे अच्छा क्या है या आपके ऑब्जेक्ट मॉडल के लिए सबसे अच्छा क्या है, लेकिन दोनों ही मामलों में, अर्थहीन कुंजी या GUID का उपयोग करना बेहतर विचार है। यह अनुक्रमण को आसान और तेज़ बनाता है, और यह आपके ऑब्जेक्ट के लिए एक पहचान है जो बदलता नहीं है।

— चार्ल्स ग्राहम
स्रोत

1

पाठ्यक्रमों के लिए घोड़ा। मेरे पूर्वाग्रह को बताने के लिए; मैं पहले एक डेवलपर हूं, इसलिए मैं मुख्य रूप से उपयोगकर्ताओं को एक काम करने वाला एप्लिकेशन देने से चिंतित हूं।

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

मैंने सिस्टम पर केवल सरोगेट कुंजियों के साथ काम किया है, और एकमात्र दोष विभाजन के लिए डेटा के अभाव का है।

अधिकांश पारंपरिक पीएल / एसक्यूएल डेवलपर्स जिनके साथ मैंने काम किया है, उनमें सरोगेट कुंजियों को प्रति तालिकाओं की संख्या के कारण पसंद नहीं किया था, लेकिन हमारे परीक्षण और उत्पादन डेटाबेस ने कभी भी पसीना नहीं उठाया; अतिरिक्त जुड़ाव अनुप्रयोग के प्रदर्शन को प्रभावित नहीं करता है। डेटाबेस बोलियों के साथ, जो "एक्स इनर ज्वाइन वाई ऑन एक्सए = वाईबी" जैसे खंडों का समर्थन नहीं करते हैं, या डेवलपर्स जो उस वाक्यविन्यास का उपयोग नहीं करते हैं, सरोगेट कुंजी के लिए अतिरिक्त जुड़ने से प्रश्नों को पढ़ने के लिए कठिन हो जाता है, और टाइप करने के लिए लंबे समय तक। check: देखिए @Tony एंड्रयूज पोस्ट लेकिन अगर आप एक ORM या किसी अन्य SQL-जेनेरेशन फ्रेमवर्क का उपयोग करते हैं तो आप इसे नोटिस नहीं करेंगे। टच-टाइपिंग भी कम करता है।

— देखेंगे
स्रोत

इसके अलावा, यदि आप वास्तव में घर चलाना चाहते हैं कि सरोगेट कुंजी बस हैं, तो उन्हें एक यादृच्छिक बड़ी संख्या में शुरू करें और अनुक्रम 1 से 3+ से बढ़ाएँ। 1. या एक से अधिक कुंजी के लिए मान उत्पन्न करने के लिए एक ही अनुक्रम का उपयोग करें।

— 23

1

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

— Lrb
स्रोत

0

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

सरोगेट बनाम प्राकृतिक / व्यावसायिक कुंजी [बंद]

सरोगेट चाबियों का नुकसान

प्राकृतिक कुंजियों पर मिथक

निष्कर्ष