एप्लिकेशन आईडी जनरेटर बनाम डेटाबेस आईडी जेनरेटर

11

डीबी जनरेटर:

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

एप्लिकेशन आईडी जेनरेटर

के रूप में जटिल आप की जरूरत के रूप में (उदाहरण के लिए, आप अगर आप चाहते हैं में आईडी ऑब्जेक्ट प्रकार सांकेतिक शब्दों में बदलना कर सकते हैं)
हार्ड अद्वितीय बनाने के लिए (जब तक आप का उपयोग किया जा सकता है UUIDs)
तुम भी करने के लिए डीबी

[संपादित करें] बात कर के बाद से UUIDs बहुत महंगे हैं (कई डीबीएस, सूचकांक fragmenta में कोई देशी समर्थन के बिना एक ID निर्दिष्ट कर सकते हैं टियन, आदि), अधिकांश ऐप्स डीबी आधारित जेनरेटर का उपयोग करते हैं।

स्रोत

2009-08-31 09:36:04

+0

उस सूची के लिए धन्यवाद। क्या आईडी जनरेटर रखने के लिए कोई सर्वोत्तम अभ्यास है? डीबी जनरेटर मेरे लिए आसान लगता है। – bastianneu

+0

मेरे संपादन देखें। जब तक आप क्लस्टरिंग सॉफ्टवेयर लिखते हैं, जनरेटर आमतौर पर डीबी में होता है। –

+0

मुझे यह उत्तर सबसे ज्यादा पसंद है, क्योंकि यह महत्वपूर्ण बातों के साथ एक साधारण सूची है जिसके बारे में आपको विचार करना है। धन्यवाद! – bastianneu

8

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

स्रोत

2009-08-31 13:12:05 HLGEM

+0

मुझे खेद है कि मुझे आपके उत्तर से बिंदु नहीं मिलता है। क्या कोई इसे साफ़ कर सकता है? – bastianneu

+3

बिंदु यह है कि यदि आप डेटाबेस को छोड़कर कहीं भी पहचान उत्पन्न करते हैं तो आप अपने डेटा को जोखिम में डाल रहे हैं। – HLGEM

+1

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

2

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

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

प्रदर्शन के लिए अपवाद हैं, लेकिन उन लोगों को देखभाल के साथ उपयोग किया जाना चाहिए और व्यवसाय-दृश्य पहचानकर्ता के साथ भ्रमित नहीं होना चाहिए।

मेरी संबंधित देखें blog post

स्रोत

2009-08-31 17:30:54

+0

+1 अच्छा पढ़ा। उस लिंक के लिए धन्यवाद – bastianneu

+2

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

+0

@Aaron: "कृपया व्यवसाय कुंजी और तकनीकी कुंजी मिश्रण न करें।" मैंने उन्हें भ्रमित नहीं किया, मैंने विशेष रूप से अंतर को संबोधित किया। @Aaron: "एक ही जन्म तिथि के साथ दो जॉन स्मिथ हैं" यह एक तकनीकी कारण नहीं, एक नए पहचानकर्ता का आविष्कार करने का एक व्यावसायिक कारण है। –

एप्लिकेशन आईडी जनरेटर बनाम डेटाबेस आईडी जेनरेटर

उत्तर

संबंधित मुद्दे