स्वाभाविक रूप से नहीं, लेकिन अगर आपके टेबल और मेमोरी कैश में बड़े बीएलओबी हैं, तो निश्चित रूप से एक प्रदर्शन हिट होगा।
हाँ, यह एक सामान्य तरीका है। आप आमतौर पर कुछ ऐसा करते हैं जैसे प्रत्येक तालिका के नाम पर फ़ोल्डर्स होते हैं, जिसमें वे जुड़े होते हैं, जिसमें केवल प्राथमिक कुंजी पर आधारित फ़ाइल नाम होते हैं (आदर्श रूप से एक पूर्णांक; निश्चित रूप से कुछ भी उपयोगकर्ता द्वारा सबमिट नहीं किया जाता है)।
क्या यह एक बेहतर विचार है? निर्भर करता है। केवल एक डेटा स्टोर रखने के लिए परिनियोजन-सरलता के फायदे हैं, और वेब उपयोगकर्ता को किसी भी चीज़ तक पहुंच लिखने के बारे में चिंता करने की आवश्यकता नहीं है। इसके अलावा अगर ऐप की कई प्रतियां चल रही हैं (उदाहरण के लिए सक्रिय-सक्रिय लोड संतुलन) तो आपको स्टोरेज को सिंक्रनाइज़ करने की आवश्यकता है, जो कि फाइल सिस्टम के मुकाबले डेटाबेस के साथ बहुत आसान है।
यदि आप ब्लॉब के बजाय फाइल सिस्टम का उपयोग करते हैं, तो सवाल यह है कि क्या आप वेब सर्वर को फ़ोल्डर में एक उपनाम इंगित करके इसे परोसने के लिए प्राप्त करते हैं?
- + सुपर फास्ट है
- + अच्छी तरह से कैश हो जाता है
- - अतिरिक्त सर्वर विन्यास:आभासी निर्देशिका; वांछित
Content-Typeलौटाने के लिए उपयुक्त फ़ाइल एक्सटेंशन की आवश्यकता है - - अतिरिक्त सर्वर कॉन्फिगरेशन:जोड़ने की जरूरत है
Content-Disposition: attachment/X-Content-Type-OptionsXSS विरोधी उपायों के हिस्से के रूप में HTML के लिए IE को सूंघने से रोकने के लिए शीर्षलेख
या क्या आप सर्वर-साइड स्क्रिप्ट को थूक कर फ़ाइल को मैन्युअल रूप से प्रस्तुत करते हैं, जैसा कि आपको एक MySQL ब्लॉब से सेवा करनी होगी?
- - संभावित रूप से धीमा है
- - ठीक से कैश करने के लिए यदि-संशोधित-चूंकि और ETag हैंडलिंग के लिए उचित मैनुअल की आवश्यकता है
- + एप्लिकेशन के स्वयं के एक्सेस नियंत्रण विधियों का उपयोग कर सकता है
- + सर्विंग स्क्रिप्ट से सही सामग्री-प्रकार और सामग्री-विस्थापन शीर्षलेख जोड़ने में आसान
यह एक व्यापार-बंद है जिसके लिए विश्व स्तर पर स्वीकृत उत्तर नहीं है।
