5
Sono consapevole che non è consigliabile memorizzare immagini come BLOB in SQL. Tuttavia, lavorare sia sul mio PC locale che su un server rende difficile sincronizzare le immagini tra i due. Ci sarebbe ancora un motivo per non utilizzare BLOB esclusivamente come backup, che creerebbe un file memorizzato nella cache localmente (per servire staticamente)?Immagine del negozio MySQL Prestazioni di cattiva pratica BLOB
In sostanza, le prestazioni sono un problema solo quando la colonna BLOB è selezionata? Se l'unico effetto sarebbe una tabella più grande, allora non vedo un motivo per non mantenere l'immagine associata direttamente alla voce della tabella.
So che questo non risponde direttamente, ma si potrebbe approfondire il motivo per cui le immagini non possono essere condivise? Potrebbero essere ospitati su un server online (o CDN)? – 1mike12
@ 1mike12 Attualmente tutto è archiviato localmente e tutti i percorsi sono relativi alla directory di base/URL del sito Web per semplificare lo sviluppo in ambienti diversi. È molto più facile quando si prova a non doversi preoccupare di rompere il sito di produzione. Solo il database MySQL è centrale. Forse in futuro passerò a un sistema centralizzato anche per le immagini, ma per ora questa è più una domanda generale di SQL in parte per curiosità. – nebkat
Non esiste pratica buona o cattiva per archiviare immagini (file) in un campo BLOB. È piuttosto dipendente dal requisito. Basato su polarizzazione: generalmente non immagazzino immagini nel file system in applicazioni Java EE su larga scala (seriamente, ero completamente stanco di farlo in passato) in quanto non possono essere sincronizzate con le rispettive operazioni di database, specialmente quando devono essere inviato a un server EE remoto. Una piccola perdita di prestazioni e/o un po 'di inefficienza della memoria del database è meno importante della correttezza e della completezza. Inoltre, i file archiviati in un database sono più sicuri. – Tiny