सबसे कुशल UUID कॉलम प्रकार क्या है

15

128 बिट UUID के भंडारण के लिए कई भंडारण विकल्प हैं:

एक बाइट [16] कॉलम
दो बिगिन / लंबे (64 बिट्स) कॉलम
एक CHAR (36) कॉलम - 32 हेक्स अंक + 4 डैश।
UUID डेटाबेस विशिष्ट कॉलम, यदि db इसका समर्थन करता है

अनुक्रमण के दृष्टिकोण से, उनमें से कौन सबसे अधिक कुशल हैं? अगर db एक समर्पित uuid प्रकार का समर्थन नहीं करता है जो 1, 2, 3 में से सबसे अच्छा उम्मीदवार है?

— व्लाद मिहलसिया
स्रोत

1

यह थोड़ा सा भी है "यह निर्भर करता है" - कार्यान्वयन की बहुत सारी विशिष्टताएं।

— क्रेग रिंगर

2

मैं कभी भी 3 नहीं चुनूंगा: कभी भी 36 बाइट्स में कुछ स्टोर न करें जब यह 16 में किया जा सकता है। मैं raw(16)ओरेकल में और uuidपोस्टग्रेक्यूएल में उपयोग करता हूं ।

— कॉलिन के टी हार्ट

1

बेहतर सरल है।

— akuzminsky

uuid>> bytea>> बाधा के textसाथ >> । देखें: dba.stackexchange.com/a/89433/3684 और dba.stackexchange.com/a/115316/3684 । CHECKvarchar(36)char(36)

— इरविन ब्रान्डेसटेटर

15

एक समर्पित uuidप्रकार PostgreSQL के लिए आपका सबसे अच्छा दांव है। अन्य DBs के साथ कहना मुश्किल है - किसी के लिए यह असंभव नहीं है uuidकि वह एक प्रकार का है जो एक साधारण बाइट प्रकार की तुलना में कम कुशलता से संग्रहीत होता है।

byteaयदि आपके पास uuidप्रकार नहीं था , तो PostgreSQL में फिर से, यूयूआईडी को स्टोर करने का एक उचित तरीका होगा । अन्य DBs के लिए यह निर्भर करता है कि वे बाइनरी डेटा को कैसे स्टोर करते हैं।

जहां संभव हो मैं हेक्स-के साथ डैश का उपयोग करने से दृढ़ता से बचूंगा। यह तुलना, सॉर्ट और स्टोर करने के लिए कम कुशल है।

तो वास्तव में, "नहीं (2) या (3)"। कभी। उपयोग (4) जहाँ समर्थित हो, (1) अन्यथा।

— क्रेग रिंगर
स्रोत

एक बात का ध्यान रखें कि PostgreSQL UUID प्रकार मूल रूप से सरणियों में समर्थित नहीं है या इसे ठीक किया गया है? postgresql.org/message-id/…

— क्रिस्टोफ रूसो

@ChristopheRoussy यह 2013 से है। यह एक मामूली निरीक्षण था। SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]

— क्रेग रिंगर

3

वरीयता क्रम में: 4,1,2,3 SQL सर्वर का उपयोग करते हुए क्लस्टर कुंजी के रूप में UUIDs का उपयोग न करें, न केवल यह बुरी तरह से टुकड़ा होगा, सभी गैर क्लस्टर अनुक्रमित में क्लस्टरिंग कुंजी का उपयोग किया जाता है और आप उन बाइट्स को जोड़ देंगे। प्रत्येक सूचकांक पंक्ति। NEWSEQUENTIALID का उपयोग करके विखंडन को कम किया जा सकता है, लेकिन आमतौर पर अन्य सूचकांक में ब्लोट को रोकने के लिए GUID पर अपनी क्लस्टरिंग कुंजी के लिए एक द्विभाषी पहचान पसंद करते हैं।

1 से अधिक 2 चुनने के बीच का अंतर इस बात पर निर्भर करेगा कि डेटाबेस एक एकल स्तंभ निश्चित सरणी पर बुनियादी प्रकार के दो स्तंभों को कितना अधिक कुशल बनाता है। डमी डेटा के साथ परीक्षण करना काफी आसान होना चाहिए। अपने प्रश्नों की गति के साथ-साथ अनुक्रमित और डेटा का आकार भी देखें। छोटा + उपवास सबसे अच्छा है!

— GilesDMiddleton
स्रोत

1

किसी को यह मान लेना होगा कि किसी भी मूल-समर्थित डेटा प्रकार को उत्पाद में उस उत्पाद के ग्राहक के रूप में एक साथ रखा जा सकता है। उसके बाद, जो भी सबसे छोटी बाइट गिनती है, आपको प्रति पृष्ठ अधिकतम पंक्तियाँ मिलती हैं।

— माइकल ग्रीन
स्रोत

सच है, लेकिन क्या यह सिर्फ बाइट का आकार है जो मायने रखता है? क्या अनुक्रमण एल्गोरिथ्म को प्रभावित नहीं करता है?

— व्लाद मिहालसी

@Vlad मैं SQL सर्वर का उपयोग करें। AFAIK सभी डेटा प्रकारों को बी-ट्री (या 2104 इन-मेमरी के लिए हैश इंडेक्स) बनाते समय ही संभाला जाता है। कर रहे हैं अच्छे कारणों संभव के रूप में संकीर्ण रूप में इस रखने के लिए।

— माइकल ग्रीन