2011-11-18 20 views
6

Eventuali duplicati:
Storing Images in DB - Yea or Nay?
Images in database vs file systemArchiviare file immagine o URL nel database MySQL? Che è migliore?

ho sviluppato un'applicazione web utilizzando tecnologie RIA (Flex + PHP + MySQL + Ajax) e ora sto facendo uno dilemma sui file di immagine.

Io uso alcune immagini nella mia app Flex, quindi penso che "potrebbe essere fantastico se li memorizzo nel database, e poi recuperare da esso, in modo conscio, mantenere il processo dovrebbe essere più facile". Ma, ecco il mio dilemma:

Devo memorizzare l'URL fisico delle mie immagini, o sta andando meglio se memorizzo direttamente l'immagine?

Per esempio, nel caso mio tavolo Cars assomiglia:

ID (autonumeric) | Source (testo)

o simile?

ID (autonumerico) | Image (LONGBLOB o blob)

So che qui ci sono persone cool che mi può rispondere a questa domanda, mi spiega che è meglio e perché :)

+0

URL, decisamente meglio. – Mob

risposta

6

Personalmente raccomando di memorizzare le immagini nel database. Ovviamente, sia vantaggi che svantaggi.

Vantaggi di memorizzazione dati BLOB nel database:

  • È facile osservare i dati BLOB sincronizzati con i rimanenti elementi nella riga.
  • I dati BLOB vengono sottoposti a backup con il database. Avere un singolo sistema di archiviazione può facilitare l'amministrazione.
  • È possibile accedere ai dati BLOB tramite il supporto XML in MySQL, che può restituire una rappresentazione base 64-codificata dei dati nel flusso XML.
  • Le operazioni di ricerca full text di MySQL (FTS) possono essere eseguite su colonne che contengono dati di carattere fisso o variabile (inclusi i dati Unicode). È anche possibile eseguire operazioni FTS con dati formattati basati su testo contenuti nei campi immagine, ad esempio documenti Microsoft Word o Microsoft Excel.

Svantaggi di memorizzare dati BLOB nel database:

considerare con attenzione quali risorse potrebbero essere meglio memorizzati nel file system, piuttosto che in un database. I buoni esempi sono le immagini che sono tipicamente referenziate tramite HTTP HREF. Questo perché:

  • Il recupero di un'immagine da un database comporta un sovraccarico significativo rispetto all'utilizzo del file system.
  • L'archiviazione su disco nelle SAN di database è in genere più costosa rispetto all'archiviazione su dischi utilizzati nelle server farm Web.
+0

Non sono affatto un esperto di DB, ma per quanto riguarda il caching dei risultati e l'utilizzo della RAM del server DB? Non aumenterebbe molto dal momento che i BLOB sarebbero stati caricati tutti nella RAM? –

4

Come regola generale si wan't per mantenere il vostro database di piccole dimensioni, quindi funzionano meglio (e anche il backup è migliore). Quindi, se è possibile memorizzare solo un riferimento al file system (percorso + nome file) o URL nel DB, sarebbe meglio.

+0

Non sono d'accordo. I database di grandi dimensioni possono funzionare altrettanto bene se piccoli se amministrati correttamente. I database sono anche una piattaforma ideale per l'archiviazione delle immagini; L'accesso a questi direttamente dal DB può risolvere un sacco di problemi quando si utilizzano sistemi più grandi, come più server Web in cui si dovrebbe iniziare a utilizzare lo storage condiviso (ha i suoi problemi) o replicare i file (più problemi). – ChrisBint

+1

@ChrisBint Se si dispone di una galleria Web ad esempio e si memorizzano le immagini sul DB, tutto il lavoro e il traffico dovrebbero passare attraverso il server DB. Se si memorizzano percorsi/URL, è possibile condividere il carico con i server Web multipli di cui si sta parlando.Ma ogni situazione richiede approcci diversi, quindi ho detto che è una regola generale, non una legge sulla pietra. –

+0

Non è possibile "condividere il carico" con più server perché è necessario capire come condividere i file. NFS? In nessun modo ... se hai perso la condivisione NFS, e allora? Almeno con un DB, li stai sincronizzando e se necessario puoi ricorrere a uno slave master. – luckytaxi

0

avrei memorizzare l'url, è meno dati e questo significa un database più piccolo e più veloce dei dati che vanno a prendere da esso;)

3

sua probabilmente una questione di preferenze personali.

Come regola generale è meglio mantenere il database piccolo. Tuttavia, quando si arriva alle applicazioni aziendali, si aggiungono regolarmente le immagini direttamente al database. Se li si posiziona sul file system, il db e il file system possono andare fuori sincrono.

CMS più grande memorizzerà regolarmente tali file nel db. Tuttavia, tieni presente che ciò richiede un dimensionamento del database più grande quando tutto sta crescendo ...

Quando si salva solo l'url e il nome, assicurarsi che questi non cambieranno in futuro.

Con i file archiviati nel database è possibile implementare la sicurezza più facilmente e non è necessario preoccuparsi di nomi di file duplicati.

1

Ho usato per memorizzare il percorso nell'URL, ma l'aggiunta di un server Web aggiuntivo al mix si è rivelata meno che ideale. Per prima cosa, dovrai condividere il percorso in cui sono memorizzate le immagini. Stavamo usando NFS e dopo un po 'è diventato lento. Abbiamo provato a sincronizzare i file da un server Web a un altro, ma il processo è diventato complicato.

Detto questo, li memorizzerei nel DB. Da allora ho spostato tutta la mia immagine/archiviazione di file su MongoDB. So che questo non soddisfa le tue esigenze, ma abbiamo provato tutto (anche S3) e non eravamo soddisfatti delle altre soluzioni. Se dovessimo, sarei sicuro di buttarli dentro MySQL.

0

Personalmente, ho sempre archiviato l'URL.

Non c'è un vero motivo per non memorizzare l'immagine direttamente nel database, ma ci sono dei vantaggi nel non salvarlo nel database.

È possibile ottenere maggiore flessibilità quando non si memorizza l'immagine nel database. Puoi spostarlo facilmente e aggiornare l'URL nel file. Quindi, se si volesse spostare l'immagine dal proprio server Web a un servizio come Flickr o Amazon Web Services, sarebbe semplice come aggiornare il collegamento ai nuovi file. Ciò consente anche un facile accesso alle reti di distribuzione dei contenuti in modo che le immagini vengano consegnate agli utenti più rapidamente.

Problemi correlati