Architettura di archiviazione dei metadati dell'entità

Question

Stiamo costruendo una soluzione per l'archiviazione dei documenti e per ogni documento abbiamo bisogno di archiviare molti metadati extra per conformarci alle normative locali, che vanno dai dati di base come titolo o descrizione alle date degli eventi rilevanti o regole di disposizione e classificazione .

Ho visto diversi tipi di soluzioni, ma nessuna mi convince:

1. Tabelle che crescono in colonne quando viene aggiunto un nuovo slot per metadati (quindi hanno tante colonne quanti metadati associati ai documenti)
2. Tabelle con molte colonne generiche di riserva. Molto simile a 1. ma le tabelle non crescono (meno autorizzazioni)
3. Una tabella di ID documento, chiavi di metadati e valori di metadati.
4. Una tabella con le definizioni dei metadati e le chiavi dei metadati in 3. sono sostituite dagli ID dei metadati. Abbiamo usato questa soluzione in passato. Le tabelle hanno milioni di righe alla fine.
5. Un campo di testo nella tabella del documento o nella tabella associata che memorizza un XML o altre informazioni strutturate con tutti i metadati in coppie chiave-valore.

Sono orientato verso il numero 5, fornendo un indice full-text parallelo (Lucene.Net? Altro?) per la ricerca per metadati pertinenti (non tutto deve essere "ricercabile").

Qualche suggerimento? Esperienze simili?

Answer 1

Tabella 1: informazioni sul documento (PK è l'ID documento)

Tabella 2: definizioni dei metadati (PK è l'ID di definizione dei metadati)

Tabella 3: ID documento, ID definizione metadati, valore metadati

Il più grande svantaggio di ciò è che dovresti avere un solo tipo (varchar, presumibilmente), o dovresti avere n colonne (dove n è il numero di tipi di dati che sei disposto a memorizzare ) e utilizza una colonna nella tabella delle definizioni dei metadati per identificare la colonna nella tabella 3 da cui estrarre il valore.

Le mie opinioni sulle 5 soluzioni elencate:

1. Le tabelle in crescita sono una seccatura e potrebbero causare problemi lungo la linea (in particolare se si desidera / è necessario un valore di metadati non annullabile).
2. odio 'risparmia colonne generiche' con passione (anche se sono popolari).
3. Chiudi, ma questo limita la flessibilità dei metadati anche più della mia soluzione. Se le chiavi e i valori dei metadati sono abbastanza semplici, potrebbe funzionare.
4. Non sono davvero sicuro di cosa tu voglia dire con questo - è lo stesso che sto proponendo, o qualcos'altro?
5. Non mi piace archiviare XML strutturato in un RDBMS: perdi la maggior parte della potenza di RDBMS facendo questo IMHO.

Questo è il mio pensiero: non ho mai progettato un sistema come questo, ma mi sono occupato di sistemi commerciali che hanno utilizzato molti di questi schemi.

Answer 2

Perché non utilizzare CouchDB ? È stato progettato proprio per soddisfare questo tipo di requisiti.

Se questa non è un'opzione, considera l'utilizzo di Lua o JSon (secondo la tua opzione n. 5) come descrittore dei metadati.

Answer 3

Forse puoi dare un'occhiata a JCR (Java Content Repository). JCR è uno standard per il repository di contenuti che cattura i requisiti comuni della gestione dei contenuti come il controllo delle versioni, la ricerca full-text e la modifica. Inoltre fornisce un livello di abstract sullo spazio di archiviazione dei contenuti, il che significa che è possibile utilizzare un'API per inserire i contenuti in qualsiasi tipo di sistema di archiviazione come database, file xml, ecc. Naturalmente è possibile aggiungere metadati al documento aggiungendo alcune proprietà a nodo del documento con API JCR. Non devi preoccuparti di come verranno archiviati il ??documento e i metadati. JCR se ne occuperà. Jackrabbit è l'implementazione di riferimento di JCR. Prova.