हम एक वेब एप्लिकेशन पर काम कर रहे हैं, जो अभी तक उपयोगकर्ताओं के लिए सुलभ नहीं है। मेरे मालिक ने देखा कि नए बनाए गए रिकॉर्ड को 10 000 से अधिक की एक आईडी मिलती है, भले ही हमारे पास तालिका में केवल 100 रिकॉर्ड हैं। उसने यह मान लिया कि किसी कारण से वेब इंटरफ़ेस वास्तविक लोगों की तुलना में 100 गुना अधिक अस्थायी रिकॉर्ड बनाता है (और उन्हें हटा देता है) और यह हमें रिलीज के कुछ महीनों के भीतर सीमा से बाहर चलाने के लिए ले जा सकता है।
मुझे नहीं लगता कि वह आईडी मुद्रास्फीति के कारण के बारे में सही है (सहकर्मी जो इस बात का जवाब दे सकता है कि वह छुट्टी पर है, इसलिए हम निश्चित रूप से नहीं जानते हैं), लेकिन चलो मान लेते हैं कि वह है। उसने कहा कि वह एक बिगिनेंट कॉलम का उपयोग करने से घृणा करेगी, और वह हमें आईडी कॉलम को स्वत: सहेजना बंद करने और सर्वर-साइड कोड लिखने के लिए पसंद करेगी, जो पहले "अप्रयुक्त" पूर्णांक को चुनता है और इसे आईडी के रूप में उपयोग करता है।
मैं एक कंप्यूटर विज्ञान स्नातक छात्र थोड़े व्यावहारिक अनुभव के साथ हूं, जो एक जूनियर डेवलपर भूमिका निभाता है। हमारे पास हमारे संगठन के सभी डेटाबेसों को प्रबंधित करने और उनमें से अधिकांश को डिजाइन करने का वर्षों का अनुभव है। मुझे लगता है कि वह इस मामले में गलत है, कि एक बिगिंट आईडी से डरने की कोई बात नहीं है, और यह कि डीबीएमएस की कार्यक्षमता की नकल करने से एंटीपैटर्न की गंध आती है। लेकिन मुझे अभी तक अपने फैसले पर भरोसा नहीं है।
प्रत्येक स्थिति के लिए और उसके खिलाफ क्या तर्क हैं? यदि हम एक बिगिंट का उपयोग करते हैं तो क्या बुरी चीजें हो सकती हैं, और पहिया ऑटोइन्क्रोमिंग कार्यक्षमता को सुदृढ़ करने के खतरे क्या हैं ? क्या कोई तीसरा समाधान है जो किसी एक से बेहतर है? आईडी फेस वैल्यू की मुद्रास्फीति से बचने के लिए उसके क्या कारण हो सकते हैं? मुझे व्यावहारिक कारणों के बारे में भी सुनने में दिलचस्पी है - शायद बिगिंट आईडी सिद्धांत रूप में काम करते हैं, लेकिन व्यवहार में सिरदर्द का कारण बनते हैं?
एप्लिकेशन को बहुत बड़ी मात्रा में डेटा को संभालने की उम्मीद नहीं है। मुझे संदेह है कि यह अगले कुछ वर्षों के भीतर 10 000 वास्तविक रिकॉर्ड तक पहुंच जाएगा।
अगर इससे कोई फर्क पड़ता है, तो हम Microsoft SQL सर्वर का उपयोग कर रहे हैं। एप्लिकेशन C # में लिखा गया है और SQL को Linq का उपयोग करता है।
अपडेट करें
धन्यवाद, मुझे मौजूदा उत्तर और टिप्पणियाँ दिलचस्प लगीं। लेकिन मुझे डर है कि आपने मेरे सवाल को गलत समझा, इसलिए उनमें वही है जो मैं जानना चाहता था।
मैं वास्तव में उच्च आईडी के वास्तविक कारण के बारे में चिंतित नहीं हूं। अगर हम इसे अपने दम पर नहीं पा सकते हैं, तो मैं एक अलग सवाल पूछ सकता हूं। इस मामले में निर्णय प्रक्रिया को समझने में मेरी दिलचस्पी क्या है। इसके लिए, मान लें कि आवेदन प्रति दिन 1000 रिकॉर्ड लिख रहा होगा, फिर उनमें से 9999 को हटा दिया जाएगा । मुझे लगभग यकीन है कि यह मामला नहीं है, लेकिन यह वही है जो मेरे बॉस ने माना था जब उसने अपना अनुरोध किया था। तो, इन काल्पनिक परिस्थितियों में, बीट का उपयोग करने या अपना स्वयं का कोड लिखने वाले पेशेवरों और विपक्षों का क्या होगा जो आईडी असाइन करेगा (एक तरह से जो पहले से हटाए गए रिकॉर्ड की आईडी का पुन: उपयोग करता है, यह सुनिश्चित करने के लिए कि कोई अंतराल नहीं है)?
वास्तविक कारण के रूप में, मुझे दृढ़ता से संदेह है कि यह इसलिए है क्योंकि हमने एक बार किसी अन्य डेटाबेस से डेटा आयात करने के लिए कोड लिखा था, अवधारणा के प्रमाण के रूप में कि बाद के प्रवास को एक निश्चित सीमा तक किया जा सकता है। मुझे लगता है कि मेरे सहयोगी ने वास्तव में आयात के दौरान कई हजार रिकॉर्ड बनाए और बाद में उन्हें हटा दिया। मुझे पुष्टि करनी होगी कि क्या वास्तव में ऐसा था, लेकिन अगर ऐसा है, तो कार्रवाई की आवश्यकता भी नहीं है।