क्या मुझे अपनी छवियों को डेटाबेस या फ़ोल्डर में स्टोर करना चाहिए?

Question

संभव डुप्लिकेट:
Storing Images in DB - Yea or Nay?

हाय

फिलहाल अपनी वेबसाइट पर प्रत्येक कंपनी है कि वे अपने प्रोफ़ाइल में जोड़ सकते 1 तस्वीर। मैं उस छवि को डेटाबेस में सहेजता हूं .... इसकी कंपनी लोगो है।

अब मैं उन्हें और तस्वीरें जोड़ने की अनुमति देना चाहता हूं। अब मुझे नहीं पता कि मुझे इसे डेटाबेस में सहेजना चाहिए या इसे फ़ोल्डर में सहेजना चाहिए ????

कारण मुझे लगता है कि फ़ोल्डर्स बेहतर होंगे क्योंकि फैंसी रजत प्रकाश किस्म सुविधाओं के साथ बहुत अच्छे लेख हैं जिनका उपयोग मैं कर सकता हूं लेकिन उनमें से सभी केवल फ़ोल्डर में सहेजी गई छवियों को पूरा करते हैं।

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

मैं अपनी वेबसाइट पर कुछ ऐसा जोड़ना चाहता हूं (छवियों के माध्यम से ब्राउज़ करना)। डेटाबेस में छवियों को सहेजते समय यह कैसे करें इस पर कोई कोड उदाहरण? मैं वीबीनेट के साथ एएसपी.नेट का उपयोग कर रहा हूं। Click here to view what i am talking about

कोई विचार विचार लोग?

सादर एटीन

Answer 1

मैंने हाल ही में दोनों तरीकों से यह किया है। मैं अपनी संपत्तियों को डीबी में रखते हुए छवियों को संग्रहीत करने के लिए निर्देशिका विधि का उपयोग करना पसंद करता हूं।

मुख्य कारण: मेरे पास क्लाइंट था जिसके लिए मैंने वेबसाइट बनाई थी। एक फोटोगैलरी अनुभाग था जिसने उन्हें नई तस्वीरें अपलोड करने की अनुमति दी जो सार्वजनिक साइट से ब्राउज़ की जा सकती थीं। मेरे ग्राहक ने अपलोड करने से पहले अपनी छवियों को अनुकूलित करने के लिए नहीं सोचा था। तो मूल रूप से हर .jpg 1 एमबी से अधिक था। एक बार जब इसे डीबी में सहेजा गया था तो मैंने एक छवि को अपडेट करने की क्षमता को जोड़ा लेकिन इसे एक समय में एक रिकॉर्ड किया जाना था।

यदि निर्देशिका में छवियों को संग्रहीत करते समय यह वही चीज़ खुश होती है तो फ़ाइलों को स्थानीय रूप से सहेजा जा सकता है, अनुकूलित किया जा सकता है और सर्वर पर वापस रखा जा सकता है।

Here is an example

Answer 2

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

Answer 3

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

Answer 4

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

अलग-अलग चीजें मेरे दोस्त, शुभकामनाएं!

Answer 5

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

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

लंबी कहानी छोटी, जहां छवियों का व्यापार मूल्य है (यानी वे सामग्री हैं, उन्हें सुरक्षा की आवश्यकता है, या वे गतिशील हैं) आपको उन्हें डीबी में स्टोर करना होगा। जहां वे स्थैतिक और तुच्छ हैं, वेबसाइट को वेबसाइट बनने दें।

Answer 6

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

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

Answer 7

मैं दोनों के लिए जाऊंगा।

सबसे पहले, डेटाबेस में प्रत्येक छवि को एक ब्लॉब कॉलम के रूप में स्टोर करें। ऐसा करके, आपको आश्वस्त किया जा सकता है कि छवि हमेशा आपके डेटाबेस बैकअप में शामिल होती है (मान लीजिए कि आप इसे करते हैं)।

दूसरा, फ़ाइल को फ़ोल्डर में कॉपी करें। ऐसा करके, आप प्रत्येक बार डेटाबेस (छवि फ़ाइल के लिए) क्वेरी से बच सकते हैं। अकेले फ़ोल्डर में भंडारण प्रभाव हो सकता है फ़ाइल ऐसे

रूप

• खो डिस्क भ्रष्ट
• फ़ाइल के कारण बैकअप आपरेशन में शामिल नहीं हैं

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

ध्यान दें, आप निम्नलिखित को देखने के लिए चाहते हो सकता है:

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

उम्मीद है कि इससे मदद मिलती है।

इस पर

Answer 8

दो विचार:

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

2. SQL सर्वर 2008 का उपयोग करें। इसमें एक नया डेटाटाइप है जिसे फाइलस्ट्रीम कहा जाता है जबकि छवियों को फाइल सिस्टम में सहेज लेगा लेकिन आपको मानक डेटाबेस क्वेरीज़ के माध्यम से इसे पुनर्प्राप्त करने की अनुमति देता है। अधिक जानकारी के लिए http://msdn.microsoft.com/en-us/library/cc949109.aspx देखें।

ये विशेष विकल्प नहीं हैं, लेकिन बहुत कम से कम, मैं सरासर तथ्य यह है कि आप एक फाइल सिस्टम आधारित योजना का उपयोग कर के बजाय भंडारण से बाहर बेहतर प्रदर्शन प्राप्त होगा के लिए विकल्प # 1 की सलाह देते हैं और एक डेटाबेस से बाहर blobs पढ़ना।

Answer 9

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

---

मेरा सुझाव: फ़ोल्डरों में अपनी छवियों को सहेजें। सिस्टम I/O संचालन के बारे में जानना ही एकमात्र आवश्यकता है।

Answer 10

AFAIK, flickr.com फ़ोल्डर्स/फ़ाइल सर्वर के साथ-साथ डीबी में संग्रहीत संदर्भ, मेटाडाटा, आदि के साथ जाता है। flickr architecture