प्राथमिक कुंजी के रूप में हमेशा एक पूर्णांक स्तंभ होने के नकारात्मक पक्ष क्या हो सकता है?

18

मैं जिस वेब एप्लिकेशन पर काम कर रहा हूं, उसके भीतर, सभी डेटाबेस ऑपरेशन एंटिटी फ्रेमवर्क ओआरएम पर परिभाषित कुछ जेनेरिक रिपॉजिटरी का उपयोग करके सारगर्भित हैं।

हालाँकि, जेनेरिक रिपॉजिटरी के लिए एक सरल डिज़ाइन होने के लिए, सभी शामिल तालिकाओं को एक अद्वितीय पूर्णांक ( Int32C # में, intSQL में) को परिभाषित करना होगा । अब तक, यह हमेशा तालिका का पीके रहा है और यह भी IDENTITY।

विदेशी कुंजियों का भारी उपयोग किया जाता है और वे इन पूर्णांक स्तंभों का संदर्भ देते हैं। वे दोनों स्थिरता के लिए और ओआरएम द्वारा नेविगेशनल गुण पैदा करने के लिए आवश्यक हैं।

एप्लिकेशन परत आमतौर पर निम्नलिखित ऑपरेशन करती है:

तालिका से प्रारंभिक डेटा लोड (*) -SELECT * FROM table
अपडेट -UPDATE table SET Col1 = Val1 WHERE Id = IdVal
हटाएं -DELETE FROM table WHERE Id = IdVal
सम्मिलित करें -INSERT INTO table (cols) VALUES (...)

कम लगातार संचालन:

थोक डालने - BULK INSERT ... into tableपीछा (*) सभी डेटा लोड से (उत्पन्न पहचानकर्ता पुनः प्राप्त करने के)
बल्क डिलीट - यह एक सामान्य डिलीट ऑपरेशन है, लेकिन ORM के दृष्टिकोण से "भारी":DELETE FROM table where OtherThanIdCol = SomeValue
बल्क अपडेट - यह एक सामान्य अपडेट ऑपरेशन है, लेकिन ORM के दृष्टिकोण से "भारी":UPDATE table SET SomeCol = SomeVal WHERE OtherThanIdCol = OtherValue

* सभी छोटे तालिकाओं को आवेदन स्तर पर कैश किया जाता है और लगभग सभी SELECTsडेटाबेस तक नहीं पहुंचेंगे। एक विशिष्ट पैटर्न प्रारंभिक भार है और बहुत से INSERTएस, UPDATEएस और DELETEएस है।

वर्तमान अनुप्रयोग उपयोग के आधार पर, किसी भी तालिका में 100M रिकॉर्ड तक पहुंचने की बहुत कम संभावना है।

प्रश्न: डीबीए के दृष्टिकोण से, क्या इस टेबल डिज़ाइन की सीमा होने से मैं महत्वपूर्ण समस्याएं उठा सकता हूं?

[संपादित करें]

उत्तर पढ़ने के बाद (महान प्रतिक्रिया के लिए धन्यवाद) और संदर्भित लेख, मुझे लगता है कि मुझे और विवरण जोड़ना होगा:

वर्तमान एप्लिकेशन की बारीकियों - मैंने वर्तमान वेब एप्लिकेशन के बारे में उल्लेख नहीं किया है, क्योंकि मैं यह समझना चाहता हूं कि क्या मॉडल को अन्य अनुप्रयोगों के लिए भी पुन: उपयोग किया जा सकता है। हालाँकि, मेरा विशेष मामला एक ऐसा अनुप्रयोग है जो एक DWH से बहुत सारे मेटाडेटा को निकालता है। स्रोत डेटा काफी गन्दा है (एक अजीब तरीके से चिह्नित किया गया है, कुछ विसंगतियां, कई मामलों में कोई प्राकृतिक पहचानकर्ता नहीं है) और मेरा ऐप स्पष्ट पृथक निकाय उत्पन्न कर रहा है। साथ ही, कई उत्पन्न किए गए पहचानकर्ता ( IDENTITY) प्रदर्शित किए जाते हैं, ताकि उपयोगकर्ता उन्हें व्यावसायिक कुंजी के रूप में उपयोग कर सकें। यह एक बड़े पैमाने पर कोड के अलावा, GUID के उपयोग को छोड़कर ।
"उन्हें एक पंक्ति को विशिष्ट रूप से पहचानने का एकमात्र तरीका नहीं होना चाहिए" (हारून बर्ट्रेंड ♦) - यह एक बहुत अच्छी सलाह है। मेरी सभी तालिकाएँ यह सुनिश्चित करने के लिए एक अद्वितीय अवधारणा को परिभाषित करती हैं कि व्यावसायिक डुप्लिकेट की अनुमति नहीं है।
फ्रंट-एंड ऐप संचालित डिज़ाइन बनाम डेटाबेस संचालित डिज़ाइन - डिज़ाइन विकल्प इन कारकों के कारण होता है
1. इकाई फ्रेमवर्क सीमाएँ - कई कॉलम पीके की अनुमति है, लेकिन उनके मूल्यों को अपडेट नहीं किया जा सकता है
2. कस्टम सीमाएँ - एक पूर्णांक कुंजी होने से डेटा संरचना और गैर-SQL कोड बहुत सरल हो जाता है। उदा: सभी सूचियों में पूर्णांक कुंजी और एक प्रदर्शित मूल्य होते हैं। अधिक महत्वपूर्ण, यह गारंटी देता है कि कैशिंग के लिए चिह्नित कोई भी तालिका एक Unique int key -> valueमानचित्र में डाल सकेगी ।
जटिल चयन क्वेरी - यह लगभग कभी नहीं होगा क्योंकि सभी छोटे (<20-30K रिकॉर्ड) टेबल डेटा को एप्लिकेशन स्तर पर कैश किया जाता है। एप्लिकेशन कोड लिखते समय यह जीवन को थोड़ा कठिन बना देता है (LINQ लिखने के लिए कठिन), लेकिन डेटाबेस को बहुत अच्छे तरीके से मारा जाता है:
1. सूची दृश्य - SELECTलोड पर कोई प्रश्न उत्पन्न नहीं करेगा (सब कुछ कैश किया गया है) या इस तरह दिखने वाले प्रश्न:
```
SELECT allcolumns FROM BigTable WHERE filter1 IN (val1, val2) AND filter2 IN (val11, val12)
```
  अन्य सभी आवश्यक मान कैश लुकअप (O (1)) के माध्यम से प्राप्त किए जाते हैं, इसलिए कोई जटिल प्रश्न उत्पन्न नहीं होगा।
2. दृश्य संपादित करें - SELECTइस तरह के बयान उत्पन्न करेंगे :
```
SELECT allcolumns FROM BigTable WHERE PKId = value1
```

(सभी फ़िल्टर और मान हैं int)

— अलेक्सई
स्रोत

आप प्रासंगिकता के इन पदों को पा सकते हैं , क्योंकि सिस्टम-जनरेटेड सरोगेट मूल्यों के साथ कॉलम के उपयोग के संबंध में कुछ तार्किक, भौतिक और व्यावहारिक पहलुओं पर चर्चा की गई है।

— एमडीसीसीएल

19

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

मैं 2010 के ब्लॉग पोस्ट में उन्हें आँख बंद करके हर एक तालिका में शामिल करता हूँ:

किक करने की बुरी आदतें: हर टेबल पर एक IDENTITY कॉलम लगाना

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

— आरोन बर्ट्रेंड
स्रोत

जल्दी जवाब देने का शुक्रिया। हां, एप्लिकेशन ORM (EF) का उपयोग करता है। इसे एकल पूर्णांक स्तंभ कुंजियों की आवश्यकता नहीं है, लेकिन मैंने कुछ सामान्य संचालन को बहुत आसान (डिज़ाइन-वार) बनाने के लिए यह प्रतिबंध पेश किया है। इसके अलावा, सभी एप्लिकेशन कैश कुंजी द्वारा तेज पुनर्प्राप्ति के लिए नक्शे (शब्दकोशों) में सब कुछ संग्रहीत करते हैं और कुंजी अद्वितीय होनी चाहिए। चूंकि, मैंने guids पर ints चुना है, इसलिए मैं किसी भी तालिका के लिए IDENTITY का उपयोग करने के लिए मजबूर हूं, जिसे मैं सम्मिलित करता हूं। निश्चित मान तालिकाओं के लिए, पहचान की आवश्यकता नहीं है।

— अलेक्सेई

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

— jpmc26

13

मेरे अनुभव से, हर तालिका के लिए एक अलग आईडी का उपयोग करने का मुख्य और भारी कारण निम्नलिखित है:

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

फिर, डीबीए के दृष्टिकोण से, डीबी को धीमा या फूला हुआ बनाने वाली चीजें निश्चित रूप से प्रति पंक्ति 4 बाइट्स (या जो कुछ भी) नहीं हैं, लेकिन गलत या लापता अनुक्रमित, भूल गए टेबल / इंडेक्स पुनर्गठन, गलत रैम / टेबलस्पेस टेस्टिंग पैरामीटर जैसी चीजें हैं। , बाँध चर और इतने पर उपयोग करने की उपेक्षा। वे 10, 100, 10000 के कारकों द्वारा DB को धीमा कर सकते हैं ... अतिरिक्त आईडी कॉलम नहीं।

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

एनबी: ध्यान दें कि आपको n:mएसोसिएशन तालिकाओं के लिए एक अलग आईडी की आवश्यकता नहीं है क्योंकि ऐसी तालिकाओं के लिए संबंधित संस्थाओं की आईडी एक प्राथमिक कुंजी बनानी चाहिए। एक पलटवार एक अजीब n:mसंगति होगी जो एक ही दो संस्थाओं के बीच कई संघों को विचित्र कारण के लिए अनुमति देती है - जिन्हें पीके बनाने के लिए अपने स्वयं के आईडी कॉलम की आवश्यकता होगी। वहाँ रहे हैं ORM पुस्तकालयों जो बहु-स्तंभ पीकेएस हालांकि नहीं संभाल सकता है, ताकि एक कारण डेवलपर्स के साथ उदार होने के लिए हो सकता है, वे इस तरह के एक पुस्तकालय के साथ काम करने के लिए किया है।

— AnoE
स्रोत

2

"अजीब n: एम एसोसिएशन जो एक ही दो संस्थाओं के बीच कई संघों की अनुमति देता है" वास्तविक जीवन में बहुत आम है। उदाहरण के लिए, एक व्यक्ति के पास एक कार है, तो आवश्यकताएं तब बदल जाती हैं जब स्वामित्व शुरू हो जाता है और समाप्त हो जाता है, (एक व्यक्ति कार को बेच सकता है और बाद में वापस खरीद सकता है, और अपने सॉफ़्टवेयर को क्रैश कर सकता है ...)

— इयान रिंगरॉज़

हाँ, कुछ ऐसा ही, @IanRingrose।

— AnoE

6

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

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

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

— nvogel
स्रोत

1

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

— डेविड एल्ड्रिज

2

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

— nvogel

1

मुझे यकीन नहीं है कि यह ऐसे प्रश्नों का निष्पादन है जो प्राथमिक समस्या है जो लोगों को इस तरह के डिजाइन के साथ है - यह क्वेरी का लेखन है जिसे वे अक्सर आपत्ति करते हैं।

— डेविड एल्ड्रिज

5

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

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

जब तक आप अलग-अलग स्रोतों से डेटा मर्ज करने की योजना नहीं बनाते हैं या आपके पास पूर्णांक आकार सीमाओं से आगे जाने वाले डेटा हो सकते हैं, तब तक आपको एक पूर्णांक PK आपको काटने नहीं जा रहा है - जब तक आप आवेषण के लिए स्थान से बाहर नहीं निकल जाते, तब तक यह सभी मजेदार और खेल है। ।

मैं कहूंगा, हालांकि, यह आपके पीके के अलावा किसी कॉलम पर आपके क्लस्टर किए गए इंडेक्स को सेट करने के लिए समझ में आ सकता है , अगर टेबल को उस तरह से अधिक बार क्वियर किया जाएगा। लेकिन यह एक बड़ा मामला है, खासकर अगर अपडेट और चयनों का थोक पीके मूल्यों पर आधारित है।

— कैम
स्रोत

2

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

— एंडी

2

नहीं। GUID का उपयोग करना मज़ेदार नहीं है। मैं उन्हें पसंद नहीं करता, लेकिन मैं कुछ उपयोग के मामलों में उनके मूल्य का सम्मान करता हूं।

— सीएएम

2

सरका दो:

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

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

— वें
स्रोत

4

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

— हारून बर्ट्रेंड

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

— TH

@AaronBertrand मैं कहूंगा कि जिस तरह से वे अधिक कुशल हो सकते हैं, अगर केवल एक जुड़ाव की आवश्यकता नहीं थी। एकमात्र स्थान जिसे मैं प्राकृतिक कुंजी का उपयोग मानता हूं, वह मानक कोड सूचियों जैसे कि ISO4127 मुद्रा कोड (जो कि मानव-पहचान योग्य हैं) के साथ है, और मैं GBP, EUR आदि का उपयोग विदेशी मुद्रा के रूप में करेंसी कोड की प्राथमिक या वैकल्पिक कुंजी के रूप में कर सकता हूं। तालिका।

— डेविड एल्ड्रिज

@ निश्चित रूप से, मैं उन मामलों के बारे में बात कर रहा था जहां जुड़ना आवश्यक है। ऐसे बहुत से मामले हैं जहां मैं नहीं चाहता कि सभी संबंधित तालिकाओं में प्राकृतिक कुंजी का प्रसार हो, क्योंकि प्राकृतिक कुंजी बदल सकती है, और यह एक दर्दनाक चीज है।

— हारून बर्ट्रेंड

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

— TH

2

आपका मार्गदर्शन करने में मदद करने के लिए आपके पास कुछ कारक हैं,

परिभाषा और युक्ति।

यदि कुछ कार्य या भौतिकी के नियमों के रूप में अद्वितीय है, तो आप सरोगेट कुंजी के साथ अपना समय बर्बाद कर रहे हैं।
विशिष्टता।

व्यक्तिगत पवित्रता, जुड़ने और उच्च-स्तरीय डेटाबेस कार्यक्षमता के लिए आपको (a) अद्वितीय स्तंभ, (b) स्तंभों की अद्वितीय श्रृंखला की आवश्यकता होगी

सभी पर्याप्त रूप से सामान्यीकृत स्कीमा (1NF) निम्नलिखित में से एक प्रदान करते हैं। यदि वे नहीं करते हैं तो आपको हमेशा एक बनाना चाहिए । यदि आपके पास रविवार को स्वयंसेवक के लिए सेट किए गए लोगों का रोस्टर है, और इसमें अंतिम नाम और पहला नाम शामिल है, तो आप जानना चाहेंगे कि आपके दो जॉब बॉब्स कब हैं।
कार्यान्वयन और अनुकूलन।

एक int एक छोटा डेटा फॉर्म है जो तुलना, और समानता के लिए तेज़ है। इसकी तुलना यूनिकोड स्ट्रिंग से करें, जिसका टकराना लोकेल (स्थान और भाषा) पर निर्भर हो सकता है। एक ASCII / UTF8 स्ट्रिंग में 4242 स्टोर करना 4 बाइट्स है। इसे एक पूर्णांक के रूप में संग्रहीत करना यह 2 बाइट्स में फिट बैठता है।

इसलिए जब यह डाउनसाइड की बात आती है तो आपको कुछ कारक मिले हैं।

भ्रम और अस्पष्टता।
1. @ एरॉन बर्ट्रेंड ब्लॉग प्रविष्टि ने इसे अच्छी तरह से गाया है । विनिर्देशन और कार्य द्वारा एक ऑर्डरड के पास स्व-दस्तावेजीकरण नहीं है , और फिर डेटाबेस कार्यान्वयन के माध्यम से " ऑर्डरड " लागू करना है। कभी-कभी आपको यह स्पष्ट करना होगा कि एक सम्मेलन बनाना है या नहीं, लेकिन इससे भ्रम पैदा होने की संभावना है।
अंतरिक्ष।

इंटेगर अभी भी पंक्ति में स्थान जोड़ते हैं। और, यदि आप उनका उपयोग नहीं कर रहे हैं तो कोई उद्देश्य नहीं है।
क्लस्टरिंग।

आप केवल अपने डेटा को एक तरह से ऑर्डर कर सकते हैं। यदि आप एक सरोगेट कुंजी लगाते हैं जिसकी आवश्यकता नहीं है, तो क्या आप उस तरह से या प्राकृतिक कुंजी के रास्ते को बंद करते हैं?

— इवान कैरोल
स्रोत

अच्छा और छोटा पेशेवरों और विपक्ष।

— अलेक्सेई

@ एलेक्सई थैंक्स, इसे चिन्हित करने पर विचार करें कि अगर आपको जो मिल रहा है उसे चुना जाए। या, स्पष्टीकरण के लिए पूछ रहा है।

— इवान कैरोल