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

हमारे वर्तमान डेटाबेस काम के हिस्से के रूप में, हम डेटाबेस अपडेट करने की प्रक्रिया से निपटने को देख रहे हैं।

एक बिंदु जो बार-बार लाया गया है, वह सिस्टम बनाम उपयोगकर्ता मानों से निपटने का है; हमारे प्रोजेक्ट उपयोगकर्ता और सिस्टम वैल्स में एक साथ संग्रहीत किया जाता है। उदाहरण के लिए...

हमारे पास टेम्पलेट्स की एक सूची है।

1, 

2, 

3, 

इन्हें ऐप में एक enum (1, 2, 3) में मैप किया गया है

फिर एक उपयोगकर्ता आता है और जोड़ता है ...

4, 

...तथा...

5, 

फिर .. हम एक अपग्रेड जारी करते हैं .. और हमारी अपग्रेड स्क्रिप्ट के हिस्से के रूप में डालें ...

 [6], 

फिर !! ... हमें नए सिस्टम टेम्पलेट में एक बग मिलती है और इसे अपडेट करने की आवश्यकता है ... समस्या यह है कि कैसे? हम आईडी 6 का उपयोग करके रिकॉर्ड अपडेट नहीं कर सकते हैं (जैसा कि हमने इसे 9, या 999 के रूप में डाला होगा, इसलिए हमें किसी अन्य तंत्र का उपयोग करके रिकॉर्ड की पहचान करनी होगी)

तो, हम इसके लिए दो संभावित समाधान आ गए हैं।

लाल कोने में (गति) ....

हम बस 5000 (या कुछ अन्य मूल्य) पर उपयोगकर्ता आईडी शुरू करते हैं और 10000 (या कुछ अन्य मूल्य) पर परीक्षण डेटा शुरू करते हैं। यह हमें सिस्टम मानों में संशोधन करने और अगली आईडी सीमा की निचली सीमा तक परीक्षण करने की अनुमति देगा।

लाभ ... त्वरित और लागू करने में आसान है,

नुकसान ... मूल्यों से बाहर हो सकता है अगर हम एक बड़ी पर्याप्त सीमा का चयन नहीं करते हैं!

नीले कोने (स्केलेबिलिटी) में ...

हम स्टोर, सिस्टम और उपयोगकर्ता डेटा को अलग से स्टोर करते हैं, GUID को आईडी के रूप में उपयोग करते हैं और दृश्य का उपयोग करके दो सूचियों को मर्ज करते हैं।

लाभ ... स्केलेबल .. डीबी आकार के संबंध में कोई सीमा नहीं है।

नुकसान .. लागू करने के लिए और अधिक जटिल। (कई को एक अद्यतन करने योग्य विचार आदि)


मैं पहले विकल्प के लिए स्क्वायरली मोटा, लेकिन मुझे वापस करने के लिए कुछ बारूद की तलाश में!

क्या किसी के पास इन दृष्टिकोणों पर कोई विचार है, या यहां तक ​​कि एक (ओं) जिसे हमने याद किया है?

0
ro fr bn

6 उत्तर

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

0
जोड़ा

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 को लक्षित कर सकते हैं। तीसरा कॉलम काम में आ जाएगा हालांकि इच्छाशक्ति पर सभी सिस्टम या उपयोगकर्ता टेम्पलेट्स को चुनने के लिए, उन्हें दो टेबलों में अलग करने की आवश्यकता के बिना (यह आईएमएचओ ओवरकिल है)।

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

रॉब जी

0
जोड़ा

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

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

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

0
जोड़ा

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

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

आईडी int

     

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

     

ध्वज enum/int/bool

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

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

0
जोड़ा

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

0
जोड़ा

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

0
जोड़ा