बेस 64 एन्कोडेड डेटा को बीएलओबी या टेक्स्ट डेटाटाइप के रूप में संग्रहीत करना

किसी को अपने डेटाबेस में बेस64-एन्कोडेड डेटा स्टोर नहीं करना चाहिए...

बेस 64 एक कोडिंग है जिसमें मनमाने ढंग से बाइनरी डेटा को केवल प्रिंट करने योग्य टेक्स्ट वर्णों का उपयोग करके दर्शाया जाता है:यह उन परिस्थितियों के लिए डिज़ाइन किया गया था जहां ऐसे बाइनरी डेटा को प्रोटोकॉल या माध्यम में स्थानांतरित करने की आवश्यकता होती है जो केवल प्रिंट करने योग्य-पाठ (जैसे एसएमटीपी/ईमेल) को संभाल सकता है। यह डेटा आकार (33%) को बढ़ाता है और एन्कोडिंग/डिकोडिंग की कम्प्यूटेशनल लागत को जोड़ता है, इसलिए जब तक बिल्कुल आवश्यक न हो, इसे टाला जाना चाहिए।

इसके विपरीत, BLOB का संपूर्ण बिंदु कॉलम यह है कि वे अपारदर्शी बाइनरी स्ट्रिंग्स को स्टोर करते हैं . तो बस आगे बढ़ें और अपना सामान सीधे अपने BLOB . में स्टोर करें पहले बेस 64-एन्कोडिंग के बिना कॉलम। (उस ने कहा, यदि MySQL के पास विशेष डेटा संग्रहीत करने के लिए अधिक उपयुक्त प्रकार है, तो आप इसके बजाय इसका उपयोग करना चाह सकते हैं:उदाहरण के लिए, जावास्क्रिप्ट स्रोतों जैसी टेक्स्ट फ़ाइलें TEXT में संग्रहीत होने से लाभ उठा सकती हैं। कॉलम जिसके लिए MySQL मूल रूप से टेक्स्ट-विशिष्ट मेटाडेटा को ट्रैक करता है—इस पर और अधिक नीचे)।

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

...जब तक इसे प्रदर्शन कारणों से कैश नहीं किया जाता...

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

हालांकि, इस अर्थ में ध्यान दें कि बेस 64-एन्कोडेड स्टोरेज केवल कैश . के रूप में कार्य कर रहा है , ठीक उसी तरह जैसे कोई प्रदर्शन कारणों से असामान्य डेटा संग्रहीत कर सकता है।

...किस मामले में यह TEXT होना चाहिए नहीं BLOB

जैसा कि ऊपर बताया गया है:TEXT . के बीच एकमात्र अंतर और BLOB कॉलम वह है, TEXT . के लिए कॉलम, MySQL अतिरिक्त रूप से टेक्स्ट-विशिष्ट मेटाडेटा को ट्रैक करता है (जैसे कि कैरेक्टर एन्कोडिंग और संयोजन ) आपके लिए। यह अतिरिक्त मेटाडेटा MySQL को स्टोरेज और कनेक्शन कैरेक्टर सेट (जहां उपयुक्त हो) के बीच मूल्यों को परिवर्तित करने और फैंसी स्ट्रिंग तुलना/सॉर्टिंग ऑपरेशन करने में सक्षम बनाता है।

सामान्यतया:यदि अलग-अलग वर्ण सेट में काम करने वाले दो क्लाइंट को समान बाइट्स . देखना चाहिए , तो आप एक BLOB . चाहते हैं कॉलम; अगर उन्हें वही अक्षर देखना चाहिए तो आप एक TEXT चाहते हैं स्तंभ।

बेस 64 के साथ, उन दो क्लाइंटों को अंततः यह पता लगाना होगा कि डेटा समान बाइट्स में डीकोड करता है; लेकिन उन्हें यह देखना चाहिए कि संग्रहीत/एन्कोडेड डेटा में समान वर्ण हैं . उदाहरण के लिए, मान लीजिए कि कोई 'Hello world!' . का बेस64-एन्कोडिंग सम्मिलित करना चाहता है (जो 'SGVsbG8gd29ybGQh' . है ) अगर इंसर्टिंग एप्लिकेशन UTF-8 कैरेक्टर सेट में काम कर रहा है, तो यह बाइट सीक्वेंस 0x53475673624738676432397962475168 भेजेगा। डेटाबेस के लिए।

• यदि उस बाइट अनुक्रम को BLOB . में संग्रहीत किया जाता है कॉलम और बाद में यूटीएफ -16 में काम कर रहे एक एप्लिकेशन द्वारा पुनर्प्राप्त किया गया, उसी बाइट्स लौटाया जाएगा—जो '升噳扇㡧搲㥹扇全' . का प्रतिनिधित्व करता है और वांछित बेस 64-एन्कोडेड मान नहीं; जबकि

• यदि उस बाइट अनुक्रम को TEXT . में संग्रहीत किया जाता है कॉलम और बाद में UTF-16 में काम कर रहे एक एप्लिकेशन द्वारा पुनर्प्राप्त किया गया, MySQL बाइट अनुक्रम को वापस करने के लिए ऑन-द-फ्लाई ट्रांसकोड करेगा 0x0053004700560073006200470038006700640032003900790062004700510068 —जो मूल बेस64-एन्कोडेड मान 'SGVsbG8gd29ybGQh' को दर्शाता है इच्छानुसार।

बेशक, आप फिर भी BLOB . का उपयोग कर सकते हैं कॉलम और कैरेक्टर एन्कोडिंग को किसी अन्य तरीके से ट्रैक करें—लेकिन यह अनावश्यक रूप से पहिया को फिर से आविष्कार करेगा, अतिरिक्त रखरखाव जटिलता और अनजाने में त्रुटियों को पेश करने के जोखिम के साथ।