2009-02-07 16 views
6

Dato un insieme di file che avranno associati i metadati, quali sono i metodi consigliati per la memorizzazione di questi metadati?Metodi per la memorizzazione dei metadati associati ai singoli file?

Alcuni formati di file supportano la memorizzazione dei metadati internamente (EXIF, ID3, ecc.), Ma non tutti i formati di file supportano questo, quindi quali sono le opzioni più generali?

Alcuni dei metadati sarebbero quasi certamente unici (titoli/descrizioni/ecc.), Mentre alcuni sarebbero ripetitivi a vari livelli (categorie/tag/ecc.).
Potrebbe anche essere utile raggruppare i metadati, se sono richiesti diversi tipi di attributo.

Idealmente, le soluzioni dovrebbero coprire i concetti, piuttosto che implementazioni linguistiche specifiche.

risposta

1

Una possibilità potrebbe essere un database relazionale, strutturato in questo modo:

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 

Questa implementazione ha alcune informazioni uniche (titolo/descrizione), ma è mirato principalmente a gruppi ripetitivi di dati.

Per alcuni requisiti, altre tabelle meno generiche possono essere più utili.


Questo ha vantaggi di questo è che i database relazionali sono molto comuni, e ovviamente molto bravo a gestire le relazioni e la memorizzazione di grandi quantità di dati.

Tuttavia, per alcuni usi un server di database comporta un sovraccarico che potrebbe non essere desiderabile. Inoltre, il server del database è diverso dai file - non siedono insieme e richiedono diversi metodi di interazione.

I database non si posizionano (facilmente) sotto il controllo della versione, il che può essere una buona o una cattiva idea, a seconda del punto di vista e delle esigenze specifiche.

1

Il testo normale presenta alcuni ovvi vantaggi rispetto a qualsiasi altra cosa. Qualcosa di simile

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

file Picasa.ini di Picasa sono un buon esempio di questo tipo di metadati. Inoltre, invece di inventare il tuo formato, potrebbe valere la pena di considerare l'XML. Ci sono molti processori DOM prontamente disponibili per gestire questo formato.

Quindi, di nuovo, se la quantità di file e le relazioni tra di loro è enorme, i database potrebbero essere migliori.

+0

[Non v'è alcuna cosa come testo normale] (http://www.joelonsoftware.com/articles/Unicode.html). In effetti sto cercando ora un modo per memorizzare la codifica dei set di caratteri del testo come metadati su un file. –

+0

Per tutti gli scopi pratici, [UTF-8] (http://utf8everywhere.org/) è in chiaro. –

4

Per memorizzare i metadati nel database presenta alcuni vantaggi ma il problema principale con il database è che i metadati non sono direttamente collegati ai dati. È più robusto se i metadati rimangono con i dati, come il file speciale nella directory o qualcosa del genere.

Alcuni file system offrono funzionalità speciali che possono essere utilizzate per i metadati, ad esempio NTFS Alternate streams. Sfortunatamente, questo può essere usato per la memorizzazione dei metadati solo in casi speciali, perché questi flussi possono essere facilmente persi quando si copiano dati su un sistema di archiviazione che non li supporta. Credo che i filesystem linux abbiano anche un meccanismo di archiviazione simile.

In ogni caso, le soluzioni più comuni sono:

  • file nascosto separato (s) (per directory) che contengono metadati
  • alcune applicazioni usano speciale directory nascosta con i metadati (come Subversion, CVS eccetera).
  • o banca dati (di vario genere) per tutti metada specifica applicazione - questo database può essere utilizzato anche per scopi di caching nella maggior parte dei casi

IMO non esiste una soluzione general purpose. Sceglierei l'archiviazione dei metadati nel file nascosto (robustezza) con l'uso del database per l'accesso rapido e la memorizzazione nella cache.

2

Penso che la "soluzione" dipenda molto da ciò che si farà con i metadati.

Ad esempio, quasi tutti i metadati memorizzati (set di dati multipli di dati scientifici) vengono tutti ritagliati e archiviati in un database. Questo ci permette di creare set di dati per preservare i metadati comuni tra i file (come dici tu, categorie e tag) mentre abbiamo strutture specifiche per i file (titolo, ora di inizio/fine, valori min/max ecc.). file nascosti, eseguiamo molte ricerche e apriamo la nostra interfaccia ai consumatori esterni tramite servizi web.

Se si memorizzano metadati che non verranno cercati, i file nascosti o un file .xml dedicato per file "reale" non è una cattiva strada da percorrere. È leggibile praticamente da qualsiasi cosa, può essere facilmente convertito in diversi formati e non andrà perso se si decide di cambiare il meccanismo di archiviazione.

I metadati dovrebbero aiutarti, non ostacolarti. Ho visto (e sono stato parte di) sistemi in cui lo stoccaggio dei metadati è diventato più oneroso rispetto alla memorizzazione dei dati effettivi, ed è diventato una responsabilità. Basta tenere a mente che cosa stai cercando di fare con esso, e non esagerare con "what ifs".

0

avrei fondamentalmente fare un DB di metadati che ha tenuto queste informazioni:

resource_table
RESOURCE_ID
resource_type (cartella, doctype, collegamento web, altro)
RESOURCE_URL (qualsiasi URL)

NOTES_TABLE
NOTE_ID
RESOURCE_NO
RESOURCE_NOTE (lungo testo)

TAGS_TABLE
TAG_ID
RESOURCE_NO
TAG_TEXT

quindi vorrei usare le note testuali campo Nota per il file/cartella/risorsa. Scegli se utilizzare 1: 1 o 1: N per questo.

Il campo tag che utilizzerei per memorizzare un numero qualsiasi di parametri ricercabili come ANNO, PROGETTO e altri valori che descriveranno e raggrupperanno il contenuto.

Poi si potrebbe aggiungere tabelle immobiliare, le parti interessate, e altre informazioni organizzazione ecc

Problemi correlati