में प्राथमिक कुंजी के रूप में यूयूआईडी का उपयोग करें मेरे ऐप को अन्य ऐप उपयोगकर्ताओं (वहां अपने डिवाइस पर) के साथ समन्वयित करने की आवश्यकता है। मैं ऑफ़लाइन संपादन का भी समर्थन करना चाहता हूं, जो उपयोगकर्ता को इंटरनेट से कनेक्ट होने पर अन्य सहयोगी उपयोगकर्ताओं के साथ सिंक्रनाइज़ किया जाता है।एंड्रॉइड: SQLite
तो उपयोगकर्ता ए कुछ बदलता है (जब वह ऑफ़लाइन है) कुछ डेटा (शब्दों में वह डेटाबेस प्रविष्टियों को अपडेट करेगा) या डेटाबेस में नए रिकॉर्ड जोड़ देगा। जब उपयोगकर्ता ए इंटरनेट से कनेक्ट हो जाता है, तो सभी परिवर्तन और नए रिकॉर्ड अन्य सहयोगी उपयोगकर्ताओं को वितरित किए जाते हैं। इसलिए उपयोगकर्ता बी को परिवर्तन/अपडेट मिलेंगे और उन्हें उपयोगकर्ता बीएस स्थानीय डिवाइस डेटाबेस में सम्मिलित/अपडेट कर सकते हैं।
लेकिन मुझे यह सुनिश्चित करने की ज़रूरत है कि डेटाबेस प्रविष्टियों के आईडी पूरे सिस्टम के साथ अद्वितीय हैं। इसलिए मुझे यूयूआईडी की तरह कुछ उपयोग करने की ज़रूरत है।
मेरा प्रश्न: क्या एक एंड्रॉइड स्क्लाइट डेटाबेस तालिका में प्राथमिक कुंजी के रूप में एक यूआईआईडी (स्ट्रिंग/वर्चर) का उपयोग करना एक बुरा विचार है जो स्वत: वृद्धि होगी?
मुझे लगता है कि प्राथमिक कुंजी के रूप में स्ट्रिंग्स (यूयूआईडी में 36 वर्ण हैं) का उपयोग करके प्रदर्शन समस्याएं होंगी।
मुझे लगता है कि पूर्णांक के बजाय यूयूआईडी इंडेक्सिंग अधिक समय लेता है (स्ट्रिंग बनाम स्ट्रिंग बनाम पूर्णांक की तुलना)। मुझे यह भी लगता है कि जब मैं यूयूआईडी का उपयोग करता हूं, हर बार जब कोई नया डेटाबेस रिकॉर्ड/एंट्री डाला जाता है तो डेटाबेस को प्राथमिक कुंजी कॉलम को फिर से संशोधित करने की आवश्यकता होती है, क्योंकि प्राथमिक कुंजी इंडेक्स अब क्रमबद्ध क्रम में नहीं है (जो तब होगा जब मैं उपयोग करूंगा पूर्णांक ऑटो वृद्धि प्राथमिक कुंजी, क्योंकि प्रत्येक भविष्य का रिकॉर्ड अंत में जोड़ा जाता है, क्योंकि नई ऑटो वृद्धिशील प्राथमिक कुंजी अब तक का सबसे बड़ा नंबर है, इसलिए सूचकांक क्रमशः क्रमबद्ध क्रम में होगा)। मुझे क्या करने की ज़रूरत है 2 - 3 टेबल पर जॉइन है। मुझे यह भी लगता है कि पूर्णांक की बजाय जॉइन पर स्ट्रिंग की तुलना डेटाबेस क्वेरी को धीमा कर देगी।
हालांकि मुझे ऐसी सहयोगी सिंकिंग प्रणाली को लागू करने की कोई अन्य संभावना नहीं दिखाई दे रही है, इसलिए मुझे यूयूआईडी का उपयोग करना चाहिए, है ना?
एक और संभावना एक पूर्णांक ऑटो वृद्धि प्राथमिक कुंजी का उपयोग करने और दूसरे कॉलम यूयूआईडी का उपयोग करने के लिए होगी। तो उपयोगकर्ताओं के स्थानीय डिवाइस पर काम करने के लिए, मैं जॉइन इत्यादि के लिए इस प्राथमिक कुंजी (पूर्णांक) का उपयोग करूंगा, जबकि मैं अन्य उपयोगकर्ताओं के साथ समन्वयित करने के लिए यूयूआईडी कॉलम का उपयोग करूंगा।
आप इस दृष्टिकोण के बारे में क्या सोचते हैं या यह आपके काम में आपकी राय में है, क्योंकि आप यूयूआईडी को सीधे प्राथमिक कुंजी के रूप में उपयोग करके एक बड़ा महत्वपूर्ण प्रदर्शन मुद्दा उम्मीद नहीं करेंगे?
कोई अन्य सुझाव?
आप यूयूआईडी को 16-बाइट बाइनरी –
@EirNym के रूप में स्टोर कर सकते हैं: यह जानना अच्छा है, हालांकि मैं यह देखने में असफल रहा कि प्रश्न, उत्तर, या मेरे उत्तर के आपके स्पष्ट डाउनवोट के साथ क्या करना है। – CommonsWare
आप बताते हैं कि ASCII प्रतिनिधित्व SQLite3 में UUID के लिए केवल एक है, और इसके लिए दोष बताएं। द्विआधारी प्रतिनिधित्व में ऐसी कोई कमी नहीं है: यह एंड्रॉइड 2.3+ वाले उपकरणों के लिए पर्याप्त तेज़ है, जिसे उस वर्ष 2013 में न्यूनतम अनुशंसा की गई थी। आज हमारे पास तेज डिवाइस हैं और हम केवल SQLite3 को डेटाबेस इंजन के रूप में उपयोग नहीं कर सकते हैं, जबकि यह सामान्य रहेगा। –