Non intrinsecamente, ma se hai grandi BLOB che intasano le tabelle e la cache di memoria, ciò comporterà sicuramente un calo delle prestazioni.
Sì, questo è un approccio comune. Di solito faresti qualcosa come avere cartelle che prendono il nome da ogni tabella a cui sono associate, contenenti nomi di file basati solo sulla chiave primaria (idealmente un numero intero; certamente mai nulla inviato dall'utente).
È un'idea migliore? Dipende. Ci sono vantaggi in termini di semplicità di implementazione nell'avere un solo archivio dati e non doversi preoccupare di concedere all'utente Web l'accesso in scrittura a qualsiasi cosa. Inoltre, se potrebbero essere in esecuzione più copie dell'app (ad es. bilanciamento del carico attivo-attivo), è necessario sincronizzare lo storage, il che è molto più semplice con un database che con un filesystem.
Se utilizzi il filesystem anziché un blob, la domanda è:fai in modo che il server Web lo serva puntando un alias nella cartella?
- + è super veloce
- + memorizza bene nella cache
- - configurazione server extra:directory virtuale; necessita di un'estensione di file appropriata per restituire il
Content-Typedesiderato - - configurazione server extra:è necessario aggiungere
Content-Disposition: attachment/X-Content-Type-Optionsheader per fermare lo sniffing di IE per HTML come parte di misure anti-XSS
o servi il file manualmente facendolo sputare da uno script lato server, come dovresti servire da un BLOB MySQL?
- - è potenzialmente lento
- - ha bisogno di un bel po' di gestione manuale If-Modified-Since e ETag per memorizzare correttamente nella cache
- + può utilizzare i metodi di controllo degli accessi propri dell'applicazione
- + facile aggiungere le intestazioni Content-Type e Content-Disposition corrette dallo script di pubblicazione
Questo è un compromesso per il quale non esiste una risposta accettata a livello globale.
