डिफ़ॉल्ट डेटाबेस आईडी; सिस्टम और उपयोगकर्ता मान

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

I have never had problems (performance or development - TDD & unit testing included) using GUIDs as the ID for my databases, and I've worked on some pretty big ones. Have a look here, here and here if you want to find out more about using GUIDs (and the potential GOTCHAS involved) as your primary keys - but I can't recommend it highly enough since moving data around safely and DB synchronisation becomes as easy as brushing your teeth in the morning :-)

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

मुझे आशा है कि वह मदद करेंगे,

रॉब जी

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

एक और विचार: किसी भी टेक्स्ट-आधारित आईडी (आवश्यक GUID नहीं) का उपयोग करें, जिसे आप सिस्टम मानों के लिए देते हैं और उपयोगकर्ता मानों के लिए किसी प्रकार के कस्टम तर्क के आधार पर यादृच्छिक स्ट्रिंग या स्ट्रिंग द्वारा उत्पन्न होता है।

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

मुझे नहीं लगता कि GUID को कोई समस्या होनी चाहिए।

यदि आप इससे बचना चाहते हैं, तो ध्वज का उपयोग करें:

आईडी int

     

टेम्पलेट जो कुछ भी

     

ध्वज enum/int/bool

ध्वज दिखाता है कि वास्तविक मान एक सिस्टम या उपयोगकर्ता मान है या नहीं।

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

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

हो सकता है कि मुझे यह नहीं मिला, लेकिन क्या आप GUID को आईडी के रूप में उपयोग नहीं कर सकते थे और अभी भी उपयोगकर्ता और सिस्टम डेटा एक साथ है? फिर आप सिस्टम डेटा को (गैर-परिवर्तनीय) GUID द्वारा एक्सेस कर सकते हैं।