Perché utilizzare i file binari per impilare versioni diverse su DMS?

Question

Perché utilizzare i file binari per impilare versioni diverse su DMS?

#1 da (2 voti)

5

Ho usato entrambi Liferay e Alfresco cercando di usarli come sistema di gestione dei documenti per una rete intranet.

Ho notato quanto segue:

Usano il file system e il database per memorizzare i file
Usano un GUID per nominare il file sul filesystem e quel GUID è utilizzato come ID nel database.
Il file con nome GUID è un file binario
Il file binario con nome GUID memorizza tutte le versioni per un determinato file
Il percorso per il file nel DMS non corrisponde a quello nel file Sistema
L'URL fa riferimento al GUID quando viene richiesto un determinato file

Quello che voglio sapere è perché è questo, e quale sarebbe il modo migliore di farlo. Ti piacerebbe come creare il file binario (zip?), E quali parti manterresti nel file binario e quali parti dovresti memorizzare nel database (meta-dati, percorso?).

Sto assumendo alcuni dei vantaggi di farlo in questo modo. Come avere lo stesso URL per un file, indipendentemente dal suo attuale percorso del documento. E con un solo file anche se il file ha cambiato nome nel tempo.

version-control database file-storage

posta edgarator 12.07.2012 - 09:40

fonte

1 risposta

Leggi altre domande sui tag version-control database file-storage

Allocazione e purezza della memoria manuale Test automatici per algoritmo di differenziazione

score 2 · Accepted Answer

La memorizzazione di blocchi binari di grandi dimensioni come file è in genere più efficiente della memorizzazione di BLOB di grandi dimensioni in un database. Dipende.

I GUID hanno il vantaggio che puoi crearne uno a caso e usarlo senza dipendere da un provider di identità. L'utilizzo di un ID basato su seme generato in un DBMS richiede che tu debba prima accedere al database prima di scrivere un file su disco, con un GUID l'ordine non ha importanza.

Le revisioni dei documenti possono adattarsi perfettamente a un modello di append. Può continuare ad aggiungere revisioni al file senza causare troppe riscritture. Consente inoltre di memorizzare in modo intelligente e di archiviare semplicemente i delta che vanno dalla revisione alla revisione, in modo simile a ciò che farebbe un repository di controllo della versione. In caso contrario, la compressione può anche fare una differenza significativa rispetto all'archiviazione delle revisioni nel proprio file.

Può anche farlo per evitare di creare troppi file su disco, che a loro volta possono avere un impatto negativo sulle prestazioni. Copiare le directory o fare backup di directory con una grande quantità di file di piccole dimensioni può essere un problema lento.

Forse non dovresti guardare i file come "file", sono solo dati. Il GUID consente il recupero. Attaccandolo nel nome del file consente al file system di aiutarlo ad afferrarlo.

Potresti fare a meno di un database, potresti importare del lavoro anche se un DB lo fa già per te. In un approccio ibrido di solito inserisco elementi nel DB su cui interrogare (ad esempio "Quali documenti sono sul percorso X?"). Ciò eviterebbe di dover creare i miei propri indici e simili attorno al repository basato su file.