पहचान कॉलम पुन: बीज: जब यह आवश्यक हो?

Question

विश्वविद्यालय में अंतिम पाठों में से एक (मैं एक छात्र हूँ) के दौरान, व्याख्याता ने हमें एक डेटाबेस (MySQL सर्वर अगर यह मायने रखता है) विकसित करने के लिए कहा और छोटे ग्राहक ऐप जो डेटाबेस को डेटा स्रोत के रूप में उपभोग करेंगे।

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

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

इसलिए मैं उत्सुक हूं कि क्या ये कारण वास्तविक हैं? मैं केवल एक मामले के बारे में सोच सकता हूं, जब पहचान कॉलम की आवश्यकता होती है - जब पहचान स्थान समाप्त हो जाता है। लेकिन यह अधिक डिज़ाइन का मुद्दा है जब पहचान कॉलम प्रकार को गलत तरीके से चुना गया था, intइसके बजाय सरल कहें bigintया uniqueidentifierजब तालिका में अरब पंक्तियाँ हों। मान लीजिए, एक पहचान स्तंभ एक क्लस्टर इंडेक्स है: क्या पहचान कॉलम में अंतराल सूचकांक के प्रदर्शन को प्रभावित कर सकता है? हो सकता है कि प्रत्येक डिलीट के बाद री-सीड के अन्य वास्तविक दुनिया के कारण हो, जिनके बारे में मुझे जानकारी नहीं है?

अग्रिम में धन्यवाद!

Answer 1

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

आपका व्याख्याता किस ब्रह्मांड से है ??

वह स्थूल रूप से अक्षम है। यदि आप ऐसा करने की कोशिश करते हैं, तो आप अपने प्रदर्शन की संभावनाओं को 10 के कारक से कम कर देंगे।

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

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

अंतराल उपयोगकर्ताओं और डीबीए के लिए एक सुविधा है, असुविधा नहीं है।

मैं एक मामले के बारे में सोच सकता हूं जहां अंतरहीन सुविधाजनक होगा - एक समय में 100 पंक्तियों के समूहों में घूमना। लेकिन एक सरल वर्कअराउंड का उपयोग करना है LIMIT 100,1।

प्रदर्शन पर अंतराल का शून्य प्रभाव है। इसमें गैर-संख्यात्मक सूचकांक शामिल हैं। और गैर-अद्वितीय सूचकांक। और समग्र सूचकांक।

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

अंतराल (कम से कम) से होते हैं: INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(स्पष्ट, या कारण के क्रैश होने का), मल्टी मास्टर (Galera और समूह प्रतिकृति सहित) प्रतिकृति। क्या तुम सच में उन लोगों के लिए workarounds के साथ आना चाहते हैं ?!

बेझिझक हमें कुछ भी करने के लिए पवित्रता की जाँच करें जो व्याख्याता कहते हैं कि संदिग्ध है।

Answer 2

एक पहचान मूल्य का पुन: उपयोग, सामान्य रूप से हतोत्साहित किया जाना चाहिए। या तो मूल्य का उपयोग पूरी तरह से आंतरिक रूप से किया जाता है, जिस स्थिति में यह वास्तविक मूल्य है, वह सारहीन है, या इसका उपयोग बाहरी रूप से भी किया जाता है, जिस स्थिति में मूल्य का पुन: उपयोग करने से गलत पहचान होने की संभावना होती है।

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

जब कंपनियों का विलय होता है या अधिग्रहण किया जाता है तो ऐसे मुद्दों को हल करना एक बड़ी परेशानी हो सकती है। उद्देश्य पर ऐसी समस्याएं पैदा करना? समझदारी नहीं है।

Answer 3

पीके आईडी मूल्यों के पुन: उपयोग में समस्याएं हैं और आम तौर पर इससे बचा जाना चाहिए।

सबसे पहले, auto_increment कॉलम का कार्यान्वयन गैपलेस होने की गारंटी प्रदान नहीं करता है। यदि आप ऑटो इंक्रीमेंट कॉलम पर एक प्रविष्टि रोलबैक करते हैं तो वास्तव में अंतराल उत्पन्न होंगे।

दूसरा अंतर आईडी मौजूदा डेटा को संदर्भित कर सकता है जो हटाए नहीं गए हैं (लापता FK बाधाओं के कारण)। यदि वे सिस्टम के बाहर संचारित सदस्य संख्याओं में अनुवाद करते हैं तो संभावित व्यावसायिक पहचान जोखिम बन जाते हैं।

तीसरा, bigint unsignedआईडी से बाहर नहीं निकलेगा एक महत्वपूर्ण समय के लिए भी एक बहुत बड़ी आवेषण दर।

अंतराल के साथ सबसे बड़ा दर्द लेखा परीक्षकों के सामने आ रहा है जो इसकी लेखापरीक्षा दोष पर जोर देते हैं। डीबीए के लिए वे जानते हैं कि अंतराल मौजूद हैं और क्यों।

Answer 4

मैं हर किसी की टिप्पणियों को प्रतिध्वनित नहीं करूंगा कि पीके का पुन: उपयोग करना एक बुरा विचार है, लेकिन मैं ऐसे समय में आया हूं जहां एक पहचान स्तंभ को फिर से बीजने की आवश्यकता है।

खुद पीके इंडेक्स का भ्रष्टाचार।

दी यह कई साल पहले MS-SQL और कई, लेकिन यह अभी भी प्रासंगिक है का उपयोग कर रहा था। कई साल पहले जिस कंपनी के लिए मैं काम करता हूं, किसी ने सोचा था कि हमारे 150+ दूरस्थ स्थानों में पीसी के सर्वरों को फिर से उपयोग करने के लिए एक अच्छा विचार होगा क्योंकि वे ग्राहकों द्वारा उपयोग किए जाने के लिए बहुत पुराने थे और फिर उन्हें एक कोठरी में चिपका दिया था। कोई वेंटिलेशन के साथ। जब नहीं क्योंकि हम सभी जानते हैं कि १२०+ रनिंग मिशन क्रिटिकल डेटाबेस के छोटे कमरे में १० साल पुराने कंप्यूटर के कबाड़ का ढेर केवल अच्छे काम कर सकता है। 40% की विफलता दर और मेरे कैरियर की पसंद पर पुनर्विचार करना। हम डेटा को कॉर्प मुख्यालय पर फिर से भेजेंगे, लेकिन अधिक बार नहीं, इन विफलताओं के परिणामस्वरूप डेटाबेस में खराब चीजें होंगी। उन चीजों में से एक डेटाबेस भ्रष्ट सूचकांक थे जो डेटाबेस और प्रतिकृति प्रक्रिया को जब्त कर लेंगे। इस महान वातावरण में दो बार, प्रतिकृति को ठीक करने का एकमात्र उपाय अनुक्रमणिका को फिर से दिखाना और फिर प्रतिकृति को पुन: स्थापित करना था। हमने सर्वरों को बाद में उन्हें पूरी तरह से खोदने से पहले बदल दिया।