एसक्यूएल

Question

में बड़े टेक्स्ट और छवियां क्या आपके SQL डेटाबेस के अंदर बड़ी मात्रा में टेक्स्ट (जैसे एचटीएमएल पेज) स्टोर करना अच्छा विचार है? या फाइल सिस्टम में इसे HTML फ़ाइलों के रूप में स्टोर करना बेहतर विचार है?

वही छवियों के लिए जाता है - क्या डेटाबेस में छवि डेटा स्टोर करना या डिस्क पर उन्हें बेहतर रखना एक अच्छा विचार है?

बड़ी मात्रा में डेटा संग्रहीत करना मुझे उदाहरण के लिए प्रदर्शन समस्याओं का कारण बनता है? भंडारण की प्रत्येक विधि के पेशेवरों और विपक्ष क्या हैं?

डेटा के आकार के संदर्भ में, इस मामले में मैं HTML के "कुछ पेज" के क्षेत्र और आकार में 500kb से कम छवियों (शायद बहुत छोटा हालांकि) के क्षेत्र में देख रहा हूं। अपने औसत लेख/ब्लॉग एंट्री/आदि पैमाने वेब पेज का उत्पादन करने के लिए पर्याप्त है।

Answer 1

डेटाबेस में बाइनरी डेटा (दस्तावेज, छवियों आदि) संग्रहीत करने के कुछ फायदे हैं।

• आप जानकारी (नाम, तारीख आदि) आप दस्तावेज़ के बारे में संग्रहीत करना चाहते हैं के रूप में ही लेन-देन में स्वयं दस्तावेज़ की अद्यतन प्रतिबद्ध कर सकते हैं। इसका मतलब है कि आपको अपनी दो चरण की प्रतिबद्धता लिखने की चिंता करने की आवश्यकता नहीं है (हालांकि आईएसआर कि SQL सर्वर 2008 के लिए इसका समाधान है)।

• आप एक बार में बहुत (दस्तावेजों और मेटाडाटा) बैकअप ले सकते हैं, फाइल सिस्टम के साथ डेटाबेस सिंक्रनाइज़ करने के लिए होने के बारे में चिंता किए बिना

• तुम बहुत बस नेट वेब सेवाओं पर दस्तावेज वितरित कर सकते हैं, के बाद से वे सीधे डेटाटेबल्स में आते हैं, और डेटाटेबल्स को डेटासेट में डालकर और इसे पारित करके आसानी से क्रमबद्ध होते हैं।

• आप अपने शेष डेटा के अनुसार ऑब्जेक्ट्स में डेटाबेस सुरक्षा लागू कर सकते हैं, और नेटवर्क फ़ाइल अनुमतियों के बारे में चिंता करने की आवश्यकता नहीं है।

यह कुछ नुकसान भी है:

• बैकअप बहुत बड़ी

• डेटाबेस में द्विआधारी वस्तु के आकार को प्राप्त कर सकते हैं काफ़ी यह फ़ाइल से भी बड़ा हो सकता है मूल रूप से आया, और इसलिए क्लाइंट-सर्वर वातावरण में, यह नेटवर्क पर उन्हें खोलने के लिए उठाए गए समय को बढ़ा सकता है।

• आवेदन के आधार पर, आपको डेटाबेस सर्वर पर लोड पर विचार करने की आवश्यकता हो सकती है यदि उसे बहुत सारे बड़े दस्तावेज़ों की सेवा करनी है।

सभी ने कहा, यह एक तकनीक है जिसका मैं व्यापक रूप से उपयोग करता हूं, और यह बहुत अच्छी तरह से काम करता है।

Answer 2

जितना अधिक आप डालते हैं, उतना ही आप आगे बढ़ेंगे ताकि आप अधिक ओवरहेड बना सकें।

यदि आपके पास एक शानदार वेब सर्वर है, तो किसी भी कारण से डेटाबेस में सभी अतिरिक्त तनाव जोड़ने में कोई बात नहीं है जब आप वेब सर्वर पर उस तनाव को प्रतिनिधि कर सकते हैं।

एक रखरखाव बिंदु से भी, यह चारों ओर घूमना और फ़ाइलों के साथ एक अच्छी तार्किक संरचना में काम करना बहुत आसान है, बल्कि डेटाबेस के साथ लगातार काम करना।

Answer 3

यह आकार का मामला है। यह इस बात पर निर्भर करता है कि आपकी छवियां/टेक्स्ट वास्तव में कितनी बड़ी हैं।

डीबी में इन मानों को संग्रहीत करने से फ़ाइल-सिस्टम आधारित दृष्टिकोण पर कई फायदे हैं, लेकिन एक निश्चित बिंदु पर यह अक्षम हो जाता है। उदाहरण के लिए, मैं एक डीबी में अत्यधिक उच्च रिज़ॉल्यूशन इमेजरी स्टोर नहीं करता।

तो यह डिग्री का सवाल है, और बदले में, इसका मतलब है कि उत्तर आपके एचडब्ल्यू संसाधनों और आपके सिस्टम के आर्किटेक्चर पर निर्भर करता है। तो मुझे विश्वास नहीं है कि आपके प्रश्न का एक सही जवाब है। हो सकता है कि आप हमें जो स्टोर करने की कोशिश कर रहे हैं और आपके सर्वर कैसा दिख रहे हैं, उसके ब्योरे के बारे में हमें और बताएं।

Answer 4

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

Answer 5

जब मैं PHP प्रोग्राम करता था तो यह मेरी दुविधाओं में से एक था। डेटाबेस में ब्लब्स जैसी छवियों को संग्रहीत करना सुरक्षा और अनुमतियों को प्रबंधित करना आसान बना सकता है, लेकिन यह महंगा है। मैं हमेशा डेटाबेस पर कुछ मेटाडेटा और फाइल सिस्टम पर बाइनरी सामग्री स्टोर करता था। छवियों तक पहुंच प्रत्यक्ष नहीं थी (<img src="image/path" />) लेकिन PHP स्क्रिप्ट्स द्वारा प्रदान की गई थी जो छवि (<img src="showimage.php?id=$id" />) दिखाने से पहले सत्र के माध्यम से उपयोगकर्ता प्रमाणीकरण और प्राधिकरणों की जांच की गई थी। मैं आपको ऐसा करने का सुझाव देता हूं (आप जिस भी प्रकार के आवेदन पर काम कर रहे हैं)।

Answer 6

कुछ और विचार करना है कि टेक्स्ट और छवियों के इन बड़े हिस्सों में कितनी बार बदलाव आएगा। डेटा में परिवर्तन विखंडन का कारण बनता है। फ्रैगमेंटेशन आपकी डेटा फ़ाइलों और आपकी डेटाबेस संरचना दोनों में हो सकता है। डेटाबेस की तुलना में विखंडन को संभालने के लिए एक फ़ाइल सिस्टम अधिक उपयुक्त है। जितनी बार एक फ़ाइल बदलती है, जितनी जल्दी प्रणाली टूट जाएगी। डेटाबेस में

Answer 7

स्टोर पाठ

हाँ, आप के रूप में ज्यादा HTML सामग्री डेटाबेस में आप कर सकते हैं के रूप में => यह बैकअप को सरल रखना चाहिए। आपको शायद एक टेम्पलेटिंग सिस्टम का उपयोग करना चाहिए ताकि आप संपूर्ण वेबपृष्ठ संरचना को प्रत्येक दस्तावेज़ के साथ स्टोर न करें, केवल उस सामग्री को संग्रहीत करें जो एक पृष्ठ से दूसरे डेटाबेस में बदलती है।

प्रैक्टिस में हमने जिन वेबसाइटों को तैनात किया है, उनमें से 10MB टेक्स्ट सामग्री से अधिक नहीं है (हम अपने स्वयं के कस्टम टेम्पलेटिंग सिस्टम का उपयोग करते हैं)। शुद्ध पाठ के 10 एमबी सामग्री (मानो या न मानो)

फाइल सिस्टम पर स्टोर चित्रों

आम तौर पर की एक बहुत कुछ है, यह सिर्फ एक बुरा विचार डेटाबेस में छवियों को स्टोर करने के है क्योंकि आप स्वैप करने की क्षमता खो है एफ़टीपी के साथ जल्दी फोटो।

रखरखाव भी इस तरह से आसान होगा। लोगो, लेख फ़ोटो और सहायक ग्राफिक्स वेबसाइट के जीवन में बहुत कुछ बदलते हैं। पाठ के विपरीत, आप फ़ाइलों के बाइनरी डेटा को डेटाबेस संपादक में बिल्कुल पेस्ट नहीं कर सकते हैं ....

इसके अलावा, यदि आपका डेटाबेस दूषित हो जाता है - जो अधिक से अधिक होता है, तो आप परेशानी में हैं डेटाबेस में छवियों को स्टोर करें। जबकि फाइल सिस्टम भ्रष्टाचार केवल सीमित संख्या में फाइलों को प्रभावित करता है। डाटाबेस भ्रष्टाचार आपको बैकअप लेगा, और यह एक समय चूसने वाला है।