I file binari pesanti non dovrebbero essere archiviati nel database? [chiuso]

No, i file binari di grandi dimensioni in genere non dovrebbero essere memorizzati nel database.

• Generalmente, il tuo filesystem fornirà un migliore caching / buffering rispetto al tuo database per i file di grandi dimensioni
• I database sono generalmente progettati e ottimizzati attorno a piccoli bit di dati - i file binari di grandi dimensioni spesso non sono ottimizzati per i database
• L'archiviazione del database è generalmente più costosa (sia in termini di tempo di CPU che di spazio su disco) rispetto all'archiviazione del filesystem
• Spesso perdi l'opportunità di ottimizzare l'invio di file a un client web quando li memorizzi in un database (ad esempio sendfile ())
• Stai mettendo un carico inutile sul database dovendo memorizzare / recuperare oggetti binari di grandi dimensioni dal db

Il motivo più importante non per utilizzare blob di grandi dimensioni è che non è possibile eseguire il flusso degli stessi: quando si esegue una query su un database, è l'intero valore della colonna o nulla. Con i file, puoi aprire un handle, quindi leggere i dati mentre vai. Non hai mai bisogno di avere l'intero file in memoria allo stesso tempo.

Allo stesso tempo, molti dei vantaggi dei database, come l'archiviazione più efficiente di molti piccoli bit di dati e una più efficiente ricerca di tali valori, garanzie ACID, ecc., diventano meno importanti quando si tratta di file di grandi dimensioni.

È una questione di vantaggi e svantaggi. I file binari nel database verranno archiviati con tutti gli altri dati, ma dovrai pagare l'overhead includendolo nel database.

Nel tuo caso, sembra che gli svantaggi includano un supporto limitato negli strumenti che stai utilizzando. Il valore di avere i dati binari nel database giustifica lo sforzo necessario per aggirare queste limitazioni?

SQL Server 2012 ora include i FileTables . Questo combina la strategia di apparire per avere i dati nel database ma utilizza la struttura dei file dietro la scena.

La tua altra preoccupazione:

I read once that if your web application goes to cloud, then it would be very difficult to keep references of files stored in file system (file paths like: ../MyFolder001/MyFile.mpg), since you don't know where those files will be distributed.

Per un'applicazione che gestisce un numero elevato di file di grandi dimensioni, è meglio trovare una soluzione cloud che consenta di memorizzarli. La modifica dei percorsi dei file (che sono probabilmente archiviati in un database) può essere gestita da:

1. memorizzando la cartella radice in una singola posizione nella tua app e sperando di mantenere il resto della cartella e della struttura dei nomi dei file.
2. aggiornamento di qualsiasi altra struttura di sottocartella nel database con uno script. Questo è il pezzo che i database gestiscono bene.

In ogni azienda in cui ho lavorato, il consenso generale è sempre stato quello di archiviare le posizioni dei file all'interno del database e dei file altrove.

In primo luogo, non sai quale dimensione dei file le persone stanno caricando o quante volte. Ci sono modi per misurare le dimensioni di un file prima che esso entri nel database e ci saranno modi programmatici per impedire alle persone di caricare più versioni, ma il punto che sto cercando di fare è che non vuoi che le prestazioni del tuo database vengano ostacolate da qualcuno che carica un file da 2 GB o 20 persone che provano a scaricare quel file da 2 GB nello stesso momento. È probabile che il tuo database abbia anche a che fare con molte altre query più piccole allo stesso tempo. Aiutalo ad aiutarti!

Questo porta al mio secondo punto. Separazione degli interessi. Un file server può occuparsi dei file, un database può memorizzare le posizioni di tali file. I problemi relativi alla memorizzazione di file, al rilevamento e alla prevenzione di virus nei file possono essere gestiti separatamente.

Ho lavorato principalmente con siti Web e applicazioni, quindi le ragioni che sto dando sono influenzate da questo.