अलग-अलग फाइलों से जुड़े मेटाडेटा को संग्रहीत करने के तरीके?

Question

मेटाडेटा से जुड़े फाइलों के संग्रह को देखते हुए, इस मेटाडेटा को संग्रहीत करने के लिए अनुशंसित विधियां क्या हैं?

कुछ फाइलें मेटाडेटा को आंतरिक रूप से संग्रहीत करने का समर्थन करती हैं (EXIF, ID3, आदि), लेकिन सभी फ़ाइल प्रारूप इसका समर्थन नहीं करते हैं, तो अधिक सामान्य विकल्प क्या हैं?

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

आदर्श रूप से, समाधान विशिष्ट भाषा कार्यान्वयन के बजाय अवधारणाओं को कवर करना चाहिए।

FILE 
f_id 
f_location 
f_title 
f_description 

ATTRIBUTE 
a_id 
a_label 

VALUE 
v_id 
v_label 

METADATA 
md_file 
md_attribute 
md_value 

इस कार्यान्वयन कुछ अद्वितीय जानकारी (शीर्षक/विवरण), है, लेकिन मुख्य रूप से डेटा का दोहराव समूहों पर लक्षित है:

Answer 1

एक विकल्प एक संबंधपरक डेटाबेस, इस तरह संरचित हो सकता है।

कुछ आवश्यकताओं के लिए, अन्य कम जेनेरिक टेबल अधिक उपयोगी हो सकते हैं।

---

यह इस होने का लाभ है कि रिलेशनल डेटाबेस बहुत आम हैं, और स्पष्ट रूप से बहुत रिश्तों को संभालने और डेटा के बहुत सारे के भंडारण में अच्छा।

हालांकि, कुछ उपयोगों के लिए डेटाबेस सर्वर एक ओवरहेड लाता है जो वांछित नहीं हो सकता है। इसके अलावा, डेटाबेस सर्वर फ़ाइलों से अलग है - वे एक साथ नहीं बैठते हैं, और बातचीत के विभिन्न तरीकों की आवश्यकता होती है।

डेटाबेस (नियंत्रण) संस्करण नियंत्रण के तहत नहीं बैठते हैं - जो आपके दृष्टिकोण और विशिष्ट आवश्यकताओं के आधार पर एक अच्छी या बुरी चीज हो सकती है।

Answer 2

सादा पाठ के किसी और चीज़ पर कुछ स्पष्ट फायदे हैं।

FileName = 'ferrari.gif' 
Title = 'My brand new car' 
Tags = 'cars', 'cool' 
Related = 'michaelknight.mp3' 

Picasa की Picasa.ini फ़ाइलें इस तरह के मेटाडेटा के लिए एक अच्छा उदाहरण हैं। इसके अलावा, अपने प्रारूप का आविष्कार करने के बजाय, एक्सएमएल विचार करने लायक हो सकता है। इस प्रारूप से निपटने के लिए बहुत आसानी से उपलब्ध डीओएम प्रोसेसर हैं।

फिर फिर, यदि उनके बीच फाइलों और संबंधों की मात्रा बहुत बड़ी है, तो डेटाबेस बेहतर हो सकते हैं।

Answer 3

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

कुछ फाइल सिस्टम विशेष कार्यक्षमता प्रदान करते हैं जिसका उपयोग मेटाडेटा के लिए किया जा सकता है - जैसे NTFS Alternate streams। दुर्भाग्यवश, इसका उपयोग केवल विशेष मामलों में मेटाडेटा स्टोरेज के लिए किया जा सकता है, क्योंकि डेटा को स्टोरेज सिस्टम में कॉपी करने पर उन धाराओं को आसानी से खोया जा सकता है जो इसका समर्थन नहीं करते हैं। मेरा मानना ​​है कि लिनक्स फाइल सिस्टम में भी इसी तरह की स्टोरेज तंत्र है।

वैसे भी, सबसे आम समाधान कर रहे हैं:

• अलग छिपा फ़ाइल (रों) (प्रति निर्देशिका) कि मेटाडाटा
• कुछ आवेदन विशेष छिपा निर्देशिका (तोड़फोड़ की तरह का उपयोग मेटाडाटा के साथ पकड़, सीवीएस आदि)।
• या डेटाबेस सभी आवेदन विशिष्ट metada के लिए (विभिन्न प्रकार के) - इस डेटाबेस ज्यादातर मामलों

IMO कोई सामान्य प्रयोजन समाधान है में कैशिंग प्रयोजनों के लिए भी इस्तेमाल किया जा सकता है। मैं तेजी से पहुंच और कैशिंग के लिए डेटाबेस के उपयोग के साथ छिपी हुई फ़ाइल (मजबूती) में मेटाडेटा का संग्रहण चुनूंगा।

Answer 4

मुझे लगता है कि "समाधान" मेटाडेटा के साथ आप क्या करने जा रहे हैं इस पर निर्भर करता है।

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

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

मेटाडाटा आपको मदद कर सकता है, आपको बाधा नहीं डालना चाहिए। मैंने सिस्टम (और इसका एक हिस्सा) देखा है जहां मेटाडेटा स्टोरेज वास्तविक डेटा संग्रहीत करने से अधिक बोझिल हो गया है, और एक देनदारी बन गई है। बस ध्यान रखें कि आप इसके साथ क्या करने की कोशिश कर रहे हैं, और अपने आप को "क्या ifs" के साथ विस्तारित न करें।

RESOURCE_TABLE
RESOURCE_ID
RESOURCE_TYPE (फ़ोल्डर, doctype, वेब लिंक, अन्य)
RESOURCE_URL (किसी भी यूआरएल)

:

Answer 5

मैं मूल रूप से एक मेटाडाटा डीबी जो इस जानकारी आयोजित होगा NOTES_TABLE
NOTE_ID
RESOURCE_NO
RESOURCE_NOTE (लंबी पाठ)

TAGS_TABLE
TAG_ID
RESOURCE_NO
TAG_TEXT

तब मैं फ़ाइल/फ़ोल्डर/संसाधन के लिए नोट फ़ील्ड शाब्दिक नोटों का प्रयोग करेंगे। चुनें कि क्या आप इसके लिए 1: 1 या 1: एन का उपयोग करेंगे।

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

तो फिर तुम मालिक, हितधारकों, और अन्य संगठन की जानकारी आदि के लिए टेबल जोड़ सकता है