अपलोड की गई छवियों, SQL डेटाबेस या डिस्क फ़ाइल सिस्टम को संग्रहीत करने के लिए सबसे अच्छी जगह क्या है?


147

मैं एक एप्लिकेशन लिख रहा हूं जो उपयोगकर्ताओं को सर्वर पर चित्र अपलोड करने की अनुमति देता है। मैं प्रति दिन सभी jpeg के बारे में 20 छवियों की उम्मीद है और शायद संपादित / resized नहीं। (यह एक और सवाल है, स्टोर करने से पहले सर्वर साइड पर छवियों का आकार कैसे बदलना है। हो सकता है कि कोई व्यक्ति टिप्पणी में या उसके लिए .NET संसाधन ड्रॉप कर सकता है)। मुझे आश्चर्य है कि अपलोड की गई छवियों को संग्रहीत करने के लिए सबसे अच्छी जगह क्या है।

  • छवियों को फ़ाइल सिस्टम में एक फ़ाइल के रूप में संग्रहीत करें और उस छवि के लिए सटीक पथ के साथ तालिका में रिकॉर्ड बनाएं।

  • या, डेटाबेस सर्वर के "छवि" या "बाइनरी डेटा" डेटा प्रकार का उपयोग करके तालिका में ही छवि को संग्रहीत करें।

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


2
मुझे यह नहीं मिला, कहाँ?
तोबियास


जवाबों:


95

मैं आम तौर पर फाइल-सिस्टम पर फाइलों को स्टोर करता हूं, क्योंकि इसके लिए वहां क्या है, हालांकि अपवाद हैं। फ़ाइलों के लिए, फ़ाइल-सिस्टम सबसे अधिक लचीला और निष्पादन योग्य समाधान (आमतौर पर) है।

डेटाबेस पर फ़ाइलों को संग्रहीत करने में कुछ समस्याएं हैं - फाइलें आम तौर पर आपकी औसत पंक्ति से बहुत बड़ी होती हैं - कई बड़ी फ़ाइलों वाले परिणाम-सेट मेमोरी की बहुत खपत करेंगे। इसके अलावा, यदि आप स्टोरेज इंजन का उपयोग करते हैं, जो लिखने के लिए टेबल-लॉक्स का उपयोग करता है (उदाहरण के लिए ISAM), तो आपकी फ़ाइलों की तालिका अक्सर आपके द्वारा संग्रहीत की जा रही फ़ाइलों के आकार / दर के आधार पर लॉक की जा सकती है।

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


7
क्या आप कृपया मुझे तकनीकी विवरण या किसी भी संकेत के संदर्भ में अंतिम पैराग्राफ (सुरक्षा के बारे में) समझा सकते हैं। धन्यवाद।
विश्वकुमार

39
(आप सभी गोगलर्स के लिए) यदि आपके पास अपनी साइट का रूट एक "सार्वजनिक" फ़ोल्डर में कॉन्फ़िगर किया गया है (जैसा कि my_website / public / बजाय my_website /) के रूप में, आप my_website / my_images फ़ोल्डर में शेष चित्रों के साथ चित्र संग्रहीत कर सकते हैं आपका ऐप। फिर आपके img टैग "my_website / avatar.png" के बजाय "my_website / image.php? Img_id = 55" का संदर्भ देंगे, और आपकी छवि .php स्क्रिप्ट, आपकी साख को सत्यापित करने और उस आईडी को पार्स करने के बाद होगी, जिसे आप वापस भेज रहे हैं, वास्तविक लौटें। छवि। इस तरह, छवि केवल उचित लॉग इन उपयोगकर्ता द्वारा देखी जा सकती है।
कप्तान हाइपरटेक्स्ट

8
हे कप्तान आपको इसे एक वास्तविक उत्तर में बदलना चाहिए ताकि आप $ $ $ $ $ पा सकें
एंड्रयू

4
कृपया सुरक्षा पर कुछ और नोट्स जोड़ें / फाइलों को अपनी वेब साइट को नष्ट करने से
एंड्रयू

1
यह पैमाने नहीं होगा, फ़ोल्डर में फ़ाइलों की संख्या की सीमा होती है और यदि आप अपनी फ़ाइलों को कई फ़ोल्डरों में विभाजित करने की योजना बनाते हैं, तो यह फाइलों को अनुक्रमित करने की जटिलताओं को जोड़ देगा (यह पहचानने के लिए कि फ़ाइल वास्तव में स्टोर कहां है)। इसके अलावा, खोज बहुत धीमी होगी।
हार्दिक

43

विकल्प बी के लिए एकमात्र लाभ एक प्रणाली में सभी डेटा है, फिर भी यह एक गलत लाभ है! आप तर्क दे सकते हैं कि आपका कोड भी डेटा का एक रूप है, और इसलिए इसे डेटाबेस में भी संग्रहीत किया जा सकता है - आप इसे कैसे पसंद करेंगे?

जब तक आपके पास कुछ अनोखा मामला न हो:

  • व्यापार तर्क कोड में है।
  • संरचित डेटा डेटाबेस (संबंधपरक या गैर-संबंधपरक) में होता है।
  • थोक डेटा स्टोरेज (फाइल सिस्टम या अन्य) में होता है।

फ़ाइलें, कोड, डेटा

फ़ाइलों को रखने के लिए फाइल सिस्टम का उपयोग करना आवश्यक नहीं है। इसके बजाय आप क्लाउड स्टोरेज (जैसे अमेज़न S3 ) या इसके ऊपर इंफ्रास्ट्रक्चर-ए-सर्विस का उपयोग कर सकते हैं (जैसे कि होमकेयर :

https://uploadcare.com/upload-api-cloud-storage-and-cdn/

लेकिन डेटाबेस में फाइलें स्टोर करना एक बुरा विचार है।



14

मुझे पता है यह एक पुरानी पोस्ट है। लेकिन इस पृष्ठ पर आने वाले कई आगंतुकों को प्रश्न से संबंधित कुछ भी नहीं मिल रहा है। खासतौर पर नौसिखिया के लिए।

हमारी वेबसाइट में चित्र या फ़ाइल कैसे अपलोड और संग्रहित करें:

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

  1. डायनामिक ब्लॉग के लिए व्यवस्थापक से छवियां आती हैं। आमतौर पर, इन छवियों को अपलोड करने से पहले अनुकूलित किया गया है।

  2. उपयोगकर्ताओं के मामले में उपयोगकर्ताओं की छवियों को अवतार जैसी छवियों को अपलोड करने की अनुमति है। या उपयोगकर्ता ब्लॉग सामग्री बना सकते हैं और पाठ संपादक से कुछ छवियां डाल सकते हैं। इस तरह की छवियां आकार की भविष्यवाणी करना मुश्किल है। उपयोगकर्ता दृश्य आकार के आकार के अनुसार छोटी सामग्री के लिए बड़ी छवियां अपलोड कर सकते हैं लेकिन छवि आकार का आकार नहीं बदल सकते।

आइटम नंबर की अनदेखी करके। 1 से ऊपर, आइटम नंबर के लिए त्वरित समाधान। अगर हमारी वेबसाइट में इमेज ऑप्टिमाइज़र फंक्शनलिटी नहीं है तो 2 को निम्नलिखित युक्तियों द्वारा अस्थायी रूप से हल किया जा सकता है:

  1. उपयोगकर्ताओं को इमेज गैलरी पर रीडायरेक्ट करके टेक्स्ट एडिटर से सीधे अपलोड करने की अनुमति न दें। इस पृष्ठ पर उपयोगकर्ताओं को सामग्री में एम्बेड करने से पहले फ़ाइल को पहले से अपलोड करना होगा। इस विधि को फ़ाइल प्रबंधक के रूप में कहा जाता है।

  2. उपयोगकर्ताओं को छवियों को अपलोड करने के लिए एक फसल छवि समारोह का उपयोग करें। यह छवि आकार को सीमित करेगा यहां तक ​​कि उपयोगकर्ता बहुत बड़ी फ़ाइल अपलोड करते हैं। अंतिम छवि फसली छवि का परिणाम है। हम सर्वर साइड में आकार को परिभाषित कर सकते हैं और केवल उदाहरण के लिए स्वीकार कर सकते हैं 500Kb या उससे कम।

अब, यह केवल अस्थायी है। अंतिम समाधान के लिए, प्रश्न दोहराया जाता है:

  • बड़ी छवियों के भंडारण को कैसे संभालें?
  • एक्सटेंशन का आकार बदलें या बदलें।
  • एक बड़ी या मध्यम वेबसाइट या ई-कॉमर्स उनकी छवियों के लिए फ़ाइल भंडारण कैसे संभालती है?

फिर हम क्या कर सकते हैं:

  1. शेयर होस्टिंग VPS से माइग्रेट करें। पर्याप्त नहीं? फिर डेडिकेटेड में अपग्रेड करके और अधिक।

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

  3. आसान तरीका सीडीएन फ़ाइल भंडारण सेवा का उपयोग करना है।

ठीक है, 1 और 2 थोड़ा महंगा है। लेकिन नहीं 3 मुझे लगता है कि सबसे अच्छा समाधान है।

कुछ CDN सेवाएँ आपको जितनी चाहें उतनी वेब फ़ाइलों को संग्रहीत करने की अनुमति देती हैं।

प्रश्न, "हमारी वेबसाइट से सीडीएन पर फ़ाइल कैसे अपलोड करें?"

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

कुछ प्रदाता हमें सीमित भंडारण और बैंडविड्थ के साथ 14 दिनों के लिए मुफ्त सेवा प्रदान करते हैं। लेकिन यह शुरुआती बिंदु के लिए ठीक होगा। एकमात्र समस्या यह है क्योंकि 'लोग कभी कोशिश नहीं करते'।

आशा है कि यह नौसिखिया के लिए मदद करेगा।


13

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

बड़े बीओएलबी जैसे कि अभी भी SQL सर्वर 2005 द्वारा पर्याप्त रूप से संभाला नहीं गया है, जो कि नवीनतम है जिसे हमने इस पर आजमाया था।

विशेष रूप से, हमने गंभीर ब्लोट देखा और मुझे लगता है कि शायद लॉकिंग समस्याएं।

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

लेकिन मैं हमेशा चीजों को थोड़ा तोड़ने के लिए उपनिर्देशिका का उपयोग करने की कोशिश करता हूं। निर्माण तिथि अक्सर इसके लिए अच्छी तरह से काम करती है:

छवियाँ / 2008/12/17 / .jpg

... यह अलगाव का एक सभ्य स्तर प्रदान करता है, और डिबगिंग के दौरान थोड़ी मदद भी करता है। एक्सप्लोरर और एफ़टीपी ग्राहक समान रूप से थोड़ा घुट सकते हैं जब वास्तव में बहुत बड़ी निर्देशिकाएं होती हैं।

संपादित करें: SQL सर्वर के अधिक हाल के संस्करणों में 2017 के लिए एक त्वरित नोट, बहुत सारे बीएलओबी से निपटने के लिए नए विकल्प हैं जो कि मैंने चर्चा की कमियों से बचने के लिए माना जाता है।

EDIT: 2020 के लिए क्विक नोट, AWS / Azure / etc में ब्लॉब स्टोरेज भी अब सालों से एक विकल्प है। यह कई वेब-आधारित परियोजनाओं के लिए एक महान फिट है क्योंकि यह सस्ता है और यह अक्सर तैनाती के आसपास कुछ मुद्दों को सरल बना सकता है, कई सर्वरों को स्केल करना, आवश्यक होने पर अन्य वातावरणों को डीबग करना आदि।


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

1
मैंने इस समस्या को पहले भी मारा था। NTFS ने एक फ़ोल्डर में कुछ 10,000 फाइलों के साथ अप्रत्याशित व्यवहार किया।
फैज

1
न केवल NTFS बल्कि BTRFS भी, जिसमें एक फ़ोल्डर में भारी मात्रा में छवियों से निपटने में भी समस्या है। यदि आप lsइसे करने की कोशिश करते हैं तो हमेशा के लिए (हैंग हो जाता है)। या हटा दें।
सूर्यप्रिया

11

मैंने हाल ही में एक PHP / MySQL ऐप बनाया है जो एक MySQL टेबल में PDF / Word फ़ाइलों को संग्रहीत करता है (अब तक प्रति फ़ाइल 40MB जितना बड़ा)।

पेशेवरों:

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

विपक्ष:

  • mysqldump को अब looooong समय लगता है क्योंकि तालिकाओं में से एक में 500MB फ़ाइल डेटा है।
  • फाइलसिस्टम की तुलना में कुल मिलाकर बहुत मेमोरी / सीपीयू कुशल नहीं है

मैं अपने कार्यान्वयन को एक सफलता कहूंगा, यह बैकअप आवश्यकताओं का ध्यान रखता है और परियोजना के लेआउट को सरल करता है। एप्लिकेशन का उपयोग करने वाले 20-30 लोगों के लिए प्रदर्शन ठीक है।


6

मैं अपनी वेबसाइट पर अपलोड की गई छवियों का उपयोग करता हूं और मैं निश्चित रूप से विकल्प क) कहूंगा।

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

यह भविष्य की जटिलताओं से बचने के लिए किसी भी अजीब चरित्र के उपयोगकर्ता के फ़ाइल नाम को छीनने में भी मदद करता है।


6

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

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


4

SQL Server 2008 में हाइब्रिड एप्रोच का एक प्रकार है जिसे रनएस्टेस रेडियो # 74 के बारे में बात की गई फिल्स्ट्रीम डेटेटाइप कहा जाता है , जो दोनों दुनिया के सर्वश्रेष्ठ की तरह है। अधिकांश लोगों के पास 2008 की भावना नहीं है, लेकिन यदि आप करते हैं, तो यह विकल्प बहुत अच्छा लगता है


4

यह मूल रूप से मैं करता हूं।

  1. एक अपलोड की गई छवि को अस्थायी निर्देशिका या मेमोरी में संग्रहीत करें।
  2. स्थायी रूप से संग्रहीत करने से पहले उस छवि को संसाधित करें। 2.1। रंग सुधार 2.2। कम्प्रेशन 2.3। छवि आयाम 2.4 के आधार पर कई प्रतियां बनाएं। .Xl, .lg, .md, .sm आदि प्रत्यय के साथ नाम बदलें
  3. फ़ोल्डर नाम के साथ एक फ़ोल्डर के अंदर सभी संसाधित छवि फ़ाइलों (एक फ़ाइल से) को पैक करें, idजिसे डेटाबेस में किसी भी पंक्ति / दस्तावेज़ के साथ संग्रहीत किया जाएगा image file name(या छवि नाम के रूप में यादृच्छिक नाम हो सकता है)।
  4. यदि मौजूद नहीं है तो yyyy / mm / d path फ़ोल्डर बनाएं । उदाहरण के लिए 2016/08/21। एक ही दस्तावेज़ और पंक्ति के लिए डेटाबेस में उस पथ और स्टोर को याद रखें।
  5. छवि idफ़ोल्डर को pathफ़ोल्डर में ले जाएं । (पथ फ़ोल्डर / var / वेब-सामग्री फ़ोल्डर में स्थित हो सकता है।)
  6. मेमोरी बफर को फ्लश करें या अस्थायी फ़ाइल को हटा दें।

जब आपको किसी दस्तावेज़ में उल्लिखित किसी भी छवि का उपयोग करने की आवश्यकता होती है, तो आपके पास फ़ोल्डर का पथ और आईडी होता है जिसमें छवियां होती हैं। उदाहरण के लिए/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg

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


3

अधिकांश कार्यान्वयन विकल्प ए हैं।

विकल्प बी के साथ, आप व्हॉट्स 4 एस की एक पूरी बड़ी खोलते हैं जब आप डेटाबेस से उन बिट्स को किसी ऐसी चीज़ में डालते हैं जो एक ब्राउज़र पर प्रदर्शित किया जा सकता है ... इसके अलावा, अगर डीबी नीचे है, तो छवियां उपलब्ध नहीं हैं।

मुझे नहीं लगता कि अंतरिक्ष बहुत अधिक एक मुद्दा है ... Terabyte ड्राइव अब एक दो सौ रुपये हैं।

हम विकल्प A के साथ लागू कर रहे हैं क्योंकि हमारे पास विकल्प B करने के लिए समय या संसाधन नहीं हैं।


3

ऑटो आकार बदलने के लिए, इमेजमाजिक को आज़माएं ... इसका उपयोग कई प्रमुख ओपन सोर्स कंटेंट / फोटो मैनेजमेंट सिस्टम के लिए किया जाता है ... और मेरा मानना ​​है कि इसके लिए कुछ .net एक्सटेंशन हैं।


2

हम ए का उपयोग करते हैं। मैं इसे एक साझा ड्राइव पर डालूंगा (जब तक कि आप एक से अधिक सर्वर चलाने की योजना नहीं बनाते हैं)।

यदि समय आता है जब यह आपके लिए नहीं होगा तो आप कैशिंग तंत्र की जांच कर सकते हैं।


2

बिल्कुल, सकारात्मक विकल्प ए। अन्य लोगों ने उल्लेख किया है कि डेटाबेस आमतौर पर बीएलओबी के साथ अच्छी तरह से व्यवहार नहीं करते हैं, चाहे वे ऐसा करने के लिए डिज़ाइन किए गए हों या नहीं। दूसरी ओर, फाइलसिस्टम इस सामान के लिए रहते हैं। आपके पास RAID स्ट्रिपिंग का उपयोग करने का विकल्प है, छवियों को कई ड्राइवों में फैलाना, यहां तक ​​कि उन्हें भौगोलिक रूप से अलग सर्वरों में फैलाना।

एक अन्य लाभ यह है कि आपका डेटाबेस बैकअप / प्रतिकृति राक्षसी होगा।


2

विकल्प ए।

एक बार छवि लोड होने के बाद आप प्रारूप को सत्यापित कर सकते हैं और सहेजने से पहले उसका आकार बदल सकते हैं। Http://www.codeproject.com पर छवियों का आकार बदलने के लिए .Net कोड के कई नमूने हैं । उदाहरण के लिए: http://www.codeproject.com/KB/cs/Photo_Resize.aspx


2

सुरक्षा कारणों से, IE की सामग्री सूँघने के कारण होने वाली समस्याओं से बचने के लिए यह सबसे अच्छा अभ्यास है जो हमलावरों को छवि फ़ाइलों के भीतर जावास्क्रिप्ट अपलोड करने की अनुमति दे सकता है, जो आपकी साइट के संदर्भ में निष्पादित हो सकते हैं। इसलिए आप इस तरह के हमले को रोकने के लिए किसी भी तरह का भंडारण करने से पहले छवियों को बदल सकते हैं (उन्हें आकार / बदल सकते हैं)। इस उत्तर के कुछ अन्य विचार हैं।


2

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

मैं आशान्वित हूं कि इससे आपको सहायता मिलेगी।


1

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

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

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


1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.