Organizzazione del database dei miei prodotti

Ti consiglio seriamente di tenere le tue immagini in una cartella sotto la directory principale del tuo server web ("htdocs" o equivalente) e di memorizzare un riferimento al nome del file nel tuo database.

In questo modo puoi selezionare il riferimento al file dal database e copiarlo in un tag "img" html e lasciare che il tuo server web e il tuo browser eseguano il lavoro pesante.

Ci sono molti vantaggi a questo: -

• database più piccolo ed efficiente
• Risposta SQL più veloce - nessun grande blob da gestire
• codice del programma molto più semplice
• tempi di risposta più rapidi per i tuoi utenti in quanto il server web offrirà file di immagini più velocemente di quanto tu possa eseguire lo streaming.
• tempi di risposta molto più rapidi se visitano di nuovo il tuo sito perché molte delle immagini saranno memorizzate nella cache del browser.

La memorizzazione dei dati di immagine binaria in un database di solito non è la migliore idea. Vedi questa domanda sull'overflow dello stack. Se hai intenzione di avere un sacco di immagini sembra che usare il filesystem si riduca meglio, ma è qualcosa che potresti fare da solo per essere sicuro. Inoltre, non sono sicuro che sia più facile memorizzare le immagini nel database rispetto al solo utilizzo del filesystem.

Per quanto riguarda la modellazione dei dati, la tua inclinazione ad avere una tabella di immagini separata con una chiave esterna per il prodotto non sembra affatto inelegante.

Se parli di numeri medio-bassi di immagini (ad esempio, in un paio o diecimila) e di traffico medio-basso, non importa molto dove li metti. O funzionerà.

Ci sono alcuni vantaggi significativi per la loro memorizzazione nel file system, tuttavia, specialmente per un'app Web. Principalmente l'immagine è utilizzabile senza una connessione al database. Quindi non avrai bisogno di uno script per estrarre l'immagine dal database e servirla. Per bassi livelli di traffico, la lettura dei BLOB non avrà un impatto notevole. Ma sotto carico elevato, vedrai rapidamente rallentare le cose mentre il server di database impiega tutto il suo tempo e fatica nel recupero delle immagini.

L'archiviazione nel filesystem non è difficile. Imposta un percorso in cui archiviarli (/ immagini). Tieni una tabella nel db che memorizza i loro metadati (nome, ID prodotto, ecc.). E quindi salvare i file lì in base al loro ID di riga univoco in quella tabella. 1.jpg, 2.jpg, ecc. Questo è molto facile da fare se si dispone di un caricamento di immagini basato sul Web nella propria app. Se si finiscono con molte immagini, basta creare una nuova directory per ogni 'migliaia', quindi '4000.jpg' è memorizzato in '4 / 4000.jpg'.

Una caratteristica chiave di un sito commerciale di successo è la velocità. La pubblicazione delle immagini dal database è lenta. Quindi memorizzare le immagini sul file system del server web è un must.

Detto questo, ci sono diverse soluzioni alternative. Quello che ci piace fare è archiviare (non servire) le immagini nel database. Eseguiamo un lavoro programmato sul server Web che legge le immagini nel database e le memorizza localmente. In questo modo, le immagini fanno parte del backup del database e aggiornarle è davvero facile. Se si scrive il lavoro in modo efficiente, può essere eseguito una volta al minuto, quindi il ritardo non è un gran problema.

SQL Server 2008 FILESTREAM opzione per un VARBINARY (MAX) la colonna è il meglio di entrambi i mondi. Le immagini vengono comunque salvate in un file per agevolare le prestazioni, ma il tuo codice verrà salvato su una tabella e il database gestirà l'inserimento dei file sul disco. Questo può gestire immagini di grandi dimensioni e traffico elevato.