मुझे आश्चर्य है, क्या ऑटो एंटरप्राइज प्राथमिक कुंजी का उपयोग करने के लिए यह बुरा या अच्छा विचार है जैसे व्यवसाय इकाई पहचानकर्ता Partner Id या Account Number?क्या व्यापार ऑब्जेक्ट पहचानकर्ता के रूप में डेटाबेस की प्राथमिक कुंजी का उपयोग करना एक बुरा विचार है?
इसके अलावा, अगर मैं उस दृष्टिकोण का चयन करूंगा तो मुझे क्या नुकसान हो सकता है?
मुझे नहीं लगता कि हर कोई एक ही राय साझा करता है, लेकिन मुझे लगता है कि यह बुरा अभ्यास है। उपयोगकर्ता के पास 'कुंजी' के रूप में उपयोगकर्ता को पास करना मेरी राय में खराब है, कई कारणों से:
हमारे उत्पादों में, हम हमेशा प्राथमिक कुंजी के बगल में 'natural key' का उपयोग करते हैं, जो कि मनुष्यों द्वारा समझा जाता है।
यदि कोई मानव समझने योग्य प्राकृतिक कुंजी उपलब्ध नहीं है, उदाहरण के लिए जब यह एक लॉगिंग टेबल है, तो आप एक कृत्रिम कुंजी पर वापस जा सकते हैं।
मेरा मानना है कि ओपी पूछ रहा है कि उनके द्वारा किए गए बाद की टिप्पणी के आधार पर इसे अपने पीके के रूप में उपयोग करना अच्छा विचार है या नहीं। इसके अतिरिक्त, एक अच्छी संख्या के लिए एक समर्थन डेवलपर भूमिका में अनुप्रयोगों के उपयोगकर्ताओं के साथ काम करने में, मैंने पाया है कि उपयोगकर्ता वास्तव में एक आईडी प्रकार संख्या पर जल्दी से झुकाव करते हैं। जैसा कि "अरे आप @ रिकॉर्ड नंबर 14567 देखेंगे और मुझे बताएंगे कि विवरण भ्रमित है या नहीं?"। मेरी चेतावनी यह है कि यदि पीयू के रूप में एक GUID का उपयोग किया जाता है, यदि ऐसा है तो हाँ प्राकृतिक कुंजी का उपयोग एक अच्छा विचार है (लेकिन मैं उस मामले में उपयोगकर्ता को वास्तविक पीके कभी नहीं दिखाऊंगा)। – MER
@mer: मैं बिल्कुल पीके को एनके के पक्ष में बदलने की सलाह नहीं देता हूं। यह भी असंभव है। –
स्पष्टता की कमी के लिए मैं क्षमा चाहता हूं। मैं यह सुझाव नहीं दे रहा था कि आप उसे पीके के रूप में प्राकृतिक कुंजी का उपयोग करने के लिए कह रहे हैं, (हालांकि यह संभव है http://www.agiledata.org/essays/keys.html (बिंदु 2), यह सिर्फ एक बुरा विचार है) । मेरा एकमात्र बिंदु यह होना चाहिए था कि, मेरे अनुभव में, उपयोगकर्ताओं को संख्या का जिक्र करने का विचार पसंद नहीं है, लेकिन फिर एक जेनरेट नंबर को किसी एप्लिकेशन में दिए गए रिकॉर्ड के संदर्भ के प्राथमिक बिंदु के रूप में त्वरित रूप से स्विच करने के लिए स्विच करें (रिकॉर्ड अर्थ किसी संग्रह में दिखाए गए सभी एकत्रित डेटा जैसे खाता #, या फ़ाइल # या प्रोजेक्ट # आदि ...)। – MER
कुंजी चुनने या डिजाइन करते समय आपको कम से कम तीन वांछनीय विशेषताओं को ध्यान में रखना चाहिए: सरलता, स्थिरता और परिचितता। व्यावहारिक रूप से लोगों को अक्सर याद रखने और शब्दों की संख्या के बजाय शब्दों और अक्षरों के साथ काम करना आसान लगता है और यही कारण है कि अल्फान्यूमेरिक पहचानकर्ता आम तौर पर संख्यात्मक पहचानकर्ताओं (अल्फान्यूमेरिक पहचानकर्ताओं के उदाहरण: कार लाइसेंस प्लेट्स, एयरलाइन उड़ान संख्या, सीट आरक्षण से अधिक आम हैं) संख्याएं, राज्य और देश कोड, डाक कोड, ईमेल पते)। इस विचार का समर्थन करने के लिए अध्ययन और अनौपचारिक साक्ष्य हैं कि अल्फान्यूमेरिक कुंजी अकेले संख्याओं की तुलना में अधिक उपयोग योग्य हैं। इसके अलावा, अल्फान्यूमेरिक पहचानकर्ता अक्सर संख्यात्मक से कम हो सकते हैं। दूसरी ओर, अनुक्रमिक संख्यात्मक-पहचानकर्ता कुछ अनुप्रयोगों के लिए बहुत आम हैं (जैसे चालान संख्या, बैंक खाता संख्या)। तो मेरा सुझाव है कि इन चीजों को निर्धारित करते समय आपको अपने उपयोगकर्ताओं/व्यावसायिक जरूरतों के जरिए निर्देशित किया जाना चाहिए।
ध्यान दें कि डीबीएमएस इंजन-स्तरीय अनुक्रम जनरेटर अक्सर उन सीमाओं के साथ आते हैं जो उन्हें कुछ अनुप्रयोगों के लिए अनुपयुक्त बनाते हैं। उदाहरण के लिए उन्हें अद्यतन करना या वितरित डेटाबेस आर्किटेक्चर में उनका उपयोग करना आसान नहीं हो सकता है। एक और आम सीमा यह है कि प्रति तालिका केवल एक "ऑटो वृद्धि" कॉलम की अनुमति दी जा सकती है, जो एक ही कुंजी के लिए सरोगेट कुंजी भी चाहते हैं, जो एक व्यापार कुंजी के रूप में उनके उपयोग को रोकता है।
बताता है कि मेरे पास पहले टिप्पणी करने के लिए कमरा नहीं था, ऑटो वृद्धिशील प्राथमिक कुंजी एप्लिकेशन डिज़ाइन में एक समस्या हो सकती है जिसमें डेटा एकाधिक डेटाबेस में अद्वितीय होना चाहिए ... इस मामले में पीके के रूप में एक GUID का सहारा लेना। हालांकि मैं जोड़ूंगा कि वास्तविक अनुप्रयोगों का उपयोग करके वास्तविक उपयोगकर्ताओं के साथ मेरा अचूक अनुभव यह रहा है कि उनका मानना है कि प्रारंभ में पूछे जाने पर एक नाम आसान हो जाएगा लेकिन आवेदन का उपयोग करने के कुछ हफ्तों के भीतर वे सरोगेट कुंजी मूल्य का अधिक से अधिक बार संदर्भित कर रहे हैं नाम, (यहां तक कि पूरी तरह से संख्यात्मक मान)। – MER
मुझे नहीं लगता कि आप कहते हैं कि उपयोग आईडी या संख्याएं स्वयं पर एक बुरा विचार है। निर्भर करता है। अक्सर, आईडी और संख्याएं बिल्कुल सही होती हैं। खुद से पूछें: आप अन्यथा किस चीज के बारे में सोच रहे थे? और, क्या यह बेहतर होगा? मुझे नहीं लगता कि या तो अनिवार्य रूप से बेहतर है। संख्याओं के साथ एक चाल, 1 से शुरू नहीं है, लेकिन एक आईडी 1000000 के साथ शुरू करें, दूसरा 20000000 के साथ, आदि – tvCa
@tvCa: कोर्स का मेरा मतलब आईडी या संख्या नहीं है। मेरा मतलब डेटाबेस विशिष्ट जानकारी के हिस्से के रूप में ऑटो वृद्धिशील आईडी है। – Vokinneberg
@ वोकिनबर्ग कृपया अपने प्रश्न को स्पष्ट करें। जब आप "व्यवसाय इकाई पहचानकर्ता के रूप में" कहते हैं तो यह एक स्पष्ट बयान नहीं है। हम में से ज्यादातर व्यवसाय के बारे में सोचेंगे क्योंकि ग्राहक का सामना करना पड़ रहा है। लेकिन आपकी टिप्पणी से पता चलता है कि आपका मतलब तालिका के लिए प्राथमिक कुंजी के लिए आदर्श है। और उस सवाल का जवाब यह है कि यह निश्चित रूप से एक पीके के लिए एक अच्छा फिट है जब आप इसे ऑटो वृद्धिशील कॉलम और पीके के रूप में परिभाषित कर रहे हैं ... जब तक आप कोई GUID उत्पन्न नहीं कर रहे हैं ... मैं इसे भी जोड़ूंगा एक ग्राहक को एक खाता संख्या दिखा रहा है जो एक ऑटो वृद्धिशील मूल्य है ठीक है ...जब तक यह GUID – MER