Domanda

Sto per implementare una funzionalità nella nostra applicazione che consenta all'utente di "caricare" un documento PDF o Microsoft PowerPoint, che l'applicazione renderà poi disponibile ad altri utenti in un visualizzatore (in modo che non possano "scaricare" nel senso 'Salva con nome...').

So già come salvare e recuperare informazioni binarie arbitrarie nelle colonne del database, ma poiché questa sarà una funzionalità comunemente utilizzata nella nostra applicazione, temo che la soluzione porterebbe a tabelle di database enormemente grandi (come sappiamo uno dei nostri clienti vorrà inserire video in documenti PowerPoint).

So che esiste un modo per creare un oggetto "directory" in Oracle, ma esiste un modo per utilizzare questa funzionalità per archiviare e recuperare file binari salvati altrove sul server database?

O sono eccessivamente paranoico riguardo alle dimensioni del database?

(per completezza la nostra applicazione è .Net WinForms utilizzando Driver CoreLab/DevArt OraDirect.Net a Oracle 10g)

È stato utile?

Soluzione

Coppia di opzioni:Potresti inserire la colonna BLOB nel proprio tablespace, con le proprie caratteristiche di archiviazione;potresti memorizzare i BLOB nella loro tabella, collegata all'altra tabella da una colonna ID.In entrambi i casi, come hai suggerito, potresti definire la colonna come BFILE, il che significa che il file effettivo è archiviato esternamente dal database in una directory.Ciò che potrebbe preoccupare è che i LOB BFILE non partecipano alle transazioni e non sono recuperabili con il resto del database.

Tutto questo è discusso nel riferimento SQL Oracle 10gR2, capitolo 2, a partire da pagina 23.

Altri suggerimenti

Immagino che dipenda da cosa consideri enormemente grande.

Dipende davvero dal caso d'uso.Se si accede ai documenti solo raramente, sarebbe opportuno inserirli nel database (con il vantaggio di ottenere backup "gratuiti", ad esempio con il database).

Se si tratta di file che verranno colpiti più e più volte, potrebbe essere meglio metterli direttamente sul disco e memorizzare semplicemente la posizione, o anche (se la larghezza di banda è molto elevata) esaminare qualcosa come MogileFS

Nessuno sarà in grado di darti una risposta sì o no per questo.

È possibile utilizzare un tipo di colonna LOB normale e impostare i parametri di archiviazione per quel campo in modo che si trovi su uno spazio tabella separato.Crea lo spazio tabella in un punto in grado di gestire enormi quantità di dati e ridurrai al minimo l'impatto.

Per essere davvero super paranoico sull'utilizzo del disco, potresti comprimere ulteriormente il tablespace contrassegnandolo come tale.Qualcosa sulla falsariga di:

Crea tableSpace binary_data1 DataFile Some_San_Location Default Compress Storage (...)

Nella mia esperienza, un semplice campo VARCHAR2 contenente il nome del file degli allegati è una soluzione migliore e più semplice.La dimensione del file system è molto più semplice da gestire rispetto alla dimensione del database.

I dati devono vivere da qualche parte, che sia interno al DB o che tu memorizzi semplicemente un collegamento a un percorso di file accessibile (dal server), stai ancora masticando spazio.

In passato ho utilizzato semplicemente campi LOB e sembrava funzionare bene.Se mantieni i dati all'interno del DB almeno mantieni bassi i problemi di backup: potresti avere molti dati di cui eseguire il backup ma quando li ripristini, saranno tutti lì.Dividere il binario significa potenzialmente rompere il DB o perdere dati se non stai attento a ciò di cui esegui il backup.

Uno dei motivi per archiviare semplicemente il collegamento o un ID che può essere utilizzato per creare il collegamento è che lo spazio di archiviazione utilizzato solitamente per i DB Oracle è piuttosto costoso.Se si hanno molti file di grandi dimensioni, in genere è molto più conveniente inserirli su un array di dischi meno costoso.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top