[JAVA] Immagini su file system o database?

[Risto]

Una domanda che mi sono fatto, nella fase di progettazione di un WEBAPP java-based è stata proprio questa: le immagini della mia applicazione dove le memorizzo su DB o su filesystem? L'applicazione in questione è molto semplice una JSP visualizza una scheda che contiene vari campi di testo, dei link a file per il loro download e una immagine, il tutto dinamicamente secondo un certo criterio. Le immagini che vengono visualizzate sono N comunque 1 per ogni scheda (dipende da quante schede inserisce l'operatore). Io ho fatto la mia scelta, dettata dalle informazioni che ho raccolto dopo essermi documentato, ma ho avuto modo di discutere con persone ben più esperte di me e i pareri sono discordanti, opposti. Chi ha ragione? Mi piacerebbe confrontare opinioni e scelte MOTIVATE, la domanda è volutamente aperta senza la mia posizione perchè non sarebbe produttiva una risposta del tipo: hai ragione tu. Voi cosa ne pensate?

Applicazione:
- Servlet container = Tomcat
- RDBMS = MySql

[andbin]

Originariamente inviato da Risto
le immagini della mia applicazione dove le memorizzo su DB o su filesystem?

Ecco in sintesi (e sperando di non dimenticare/sbagliare qualcosa ):

Vantaggi del file-system:

• Ogni immagine è un file "fisico", sai dove sono memorizzate e se qualcosa non quadra o va storto (nomi, path, ecc...) puoi sempre andare a "guardare" sul file-system tramite gli strumenti che hai a disposizione (qui dipende da quale controllo/accesso hai sulla macchina, se accesso diretto "fisico", se accesso esterno tramite SSH o FTP o da un file manager, ecc...).
  Essendo file fisici puoi anche visualizzare direttamente la immagine (anche qui dipende da cosa puoi fare).
• Nel database basta mettere un semplice campo che contiene nome (anche con path eventualmente parziale/relativo) della immagine.
• Se il file è memorizzato in una locazione sul file-system accessibile tramite un URL su HTTP (cioè non in directory protette o zone non sotto la "root" del sito), nella pagina web puoi mettere direttamente un <img> con il src che punta direttamente alla immagine. E basta.

Svantaggi del file-system:

• Devi avere i permessi per scrivere sul file-system.
• Devi stabilire una locazione e un sistema di denominazione dei file che eviti potenziali conflitti di nomi.
• Se i file sono memorizzati in locazioni non accessibili tramite URL devi realizzare una "risorsa" dinamica (in Java EE una "servlet" ad esempio) che legge il file e ne invia i dati sulla response, dovendo pure impostare correttamente il content-type della response (che puoi ricavare dal nome del file). In questa situazione il <img> nella pagina deve puntare a questa risorsa dinamica con in più un "parametro" che indica cosa scaricare (es. il ID del record sulla tabella dove c'è il nome del file).

Vantaggi del DB:

• La immagine è inglobata nel record (tipicamente in un campo BLOB o tipo simile), non devi preoccuparti di dove sia fisicamente e non devi stabilire locazioni o sistemi di denominazione dei file.
• Se elimini un record, elimini anche la immagine. Se fai un backup della tabella, sta tutto insieme. Difficilmente hai situazioni di incongruenza in cui es. hai un file immagine non più referenziato o un record ma senza la immagine (perché cancellata per sbaglio).

Svantaggi del DB:

• Le immagini non le puoi vedere direttamente, non sono file "fisici".
• Qualunque cosa devi fare con la immagine (scriverla, leggerla o solo determinare la lunghezza), devi comunque accedere alla tabella.
• Devi comunque, in ogni caso, realizzare una risorsa "dinamica" che legge il record, estrae il BLOB, legge il suo stream di dati e lo invia sulla response. E devi impostare il giusto content-type. E il tipo del file (es. estensione o direttamente il content-type) lo devi memorizzare in qualche modo nel record, altrimenti non c'è modo di sapere facilmente che tipo di immagine è. Anche qui il <img> punta alla risorsa dinamica specificando il parametro per trovare il record.