Memorizzare immagini nel database o in file con un collegamento al database?


22

È appropriato archiviare i file di immagine nel database? O sarebbe meglio archiviare solo il percorso del file nel database, mantenendo il file stesso sul server?

Ci sono altri metodi per farlo bene?

Risposte:


22

Vi consiglio caldamente di archiviare le immagini nel filesystem e non nel database.

La memorizzazione di immagini nel database presenta diversi svantaggi:

  • Il database potrebbe aumentare in modo imprevisto. A volte lo spazio è un problema. Ad esempio con SQL Server Express hai un limite di 4 GB.

  • Le migrazioni dei dati possono diventare un problema, ad esempio se si passa da SQL Server a Oracle

  • Le query possono diventare molto lente e avrai un carico elevato del database

  • L'interoperabilità con altre applicazioni è migliore se le immagini si trovano sul filesystem e altre applicazioni usano un database diverso. Puoi anche accedervi direttamente e non hai bisogno di strumenti di database.

  • Peggio delle prestazioni in generale

  • Probabilmente dovrai creare file temporanei quando recuperi comunque le immagini dal database. Non è necessario.

Questi svantaggi superano di gran lunga il costo di mantenere sincronizzati con il filesystem i percorsi delle immagini archiviate nel database. Ci sono solo alcuni casi speciali in cui è meglio archiviare le immagini nel database.


11

Ricerca su SQL Server 2005 e sul file system NTFS (Microsoft) per confrontare le prestazioni CRUD: BLOB o no BLOB . Questo studio è stato condotto anche in un'applicazione web. Hai elencato un altro database (MySQL) e suppongo che non stai usando Windows Server per il tuo sito PHP, quindi sarebbe interessante se qualcuno avesse fatto uno studio simile su tecnologie diverse.

Si scopre che dipende dalla dimensione dei file. SQL Server preferisce BLOB (2x migliori) di 256 KB o meno e il file system privilegia i file di 1 MB +. I file system in questo studio gestiscono la frammentazione meglio del database, quindi se aggiorni costantemente questi file o questo sistema cresce nel tempo, la frammentazione sarà un fattore più importante per cui il file system farà un lavoro migliore.

Devi determinare quanto è responsabile il tuo sito per la gestione di questi file. Se stai costruendo un sito per gli agenti dei sinistri assicurativi per caricare le foto di un incidente, è meglio avere il controllo delle transazioni e assicurarti che quei file siano sul server. Buoni database fanno questo per te, quindi come sviluppatore, hai aggiunto pressione.

Replica, backup, disaster recovery, frammentazione, capacità residua del disco e prestazioni nel tempo devono essere prese in considerazione durante la progettazione. Questo è solo uno studio sulla versione precedente di SQL Server e, come altri produttori di database, suppongo che la gestione di file e binari di grandi dimensioni sia una grande arena competitiva.


Potresti anche prendere in considerazione soluzioni integrate. Ad esempio, su SQL Server sono presenti FILESTREAM e Archivio BLOB remoto .
Fernando Correia,

4

Se hai un numero enorme di immagini, memorizzarle in un database potrebbe rimuovere i problemi con l'esaurimento degli inode a livello di file system.

Comunque questo problema sarebbe meglio risolto usando un filesystem più appropriato e qualunque misura sia consigliata con quel filesystem sull'organizzazione.

Altrimenti, la memorizzazione di immagini in un database è un completo spreco di risorse. Memorizza il percorso come hai detto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.