Il modo migliore la memorizzazione di file binari o di immagine

Question

Qual è il modo migliore la memorizzazione binaria o immagine file?

1. database Sistema
2. File Sistema

La prego quindi di spiegare , perché?

Answer 1

Non c'è modo migliore vero, solo un mucchio di compromessi.

Pro Database :
1. Molto più facile da affrontare in un ambiente cluster.
2. Non richiede risorse aggiuntive, come un file server.
3. Non c'è bisogno di impostare le operazioni "Sync" nel ambiente equilibrato carico.
4. I backup includono automaticamente i file.

Database Contro :
1. Dimensioni / Crescita del database.
2. A seconda del DB Server e la lingua, potrebbe essere difficile da mettere in e recuperare.
3. Velocità / prestazioni.
4. A seconda del DB server, è necessario virus eseguire la scansione dei file al momento del caricamento e l'esportazione.

---

Pro File :
1. Per le installazioni singole singoli DB server web /, è veloce.
2. ben compreso capacità di manipolare i file. In altre parole, è facile spostare i file in una posizione diversa, se si esaurisce lo spazio su disco.
3. virus possono eseguire la scansione quando i file sono "a riposo". Ciò consente di usufruire degli aggiornamenti dello scanner.

Contro File :
1. In ambienti server Web Multi, richiede una quota accessibile. Che dovrebbe anche essere raggruppati per il failover.
2. requisiti di sicurezza supplementari per gestire l'accesso ai file. Bisogna stare attenti che il server web e / o condividere non consente l'esecuzione di file.
3. I backup transazionali devono prendere il file system in considerazione.

---

È possibile che questo detto, SQL 2008 ha una cosa che si chiama FILESTREAM che unisce due mondi. Si carica al database e memorizza in modo trasparente i file in una directory sul disco. Quando si recuperano è possibile estrarre dal database; oppure si può andare direttamente a dove vive sul file system.

Answer 2

A favore di Memorizzazione dei file binari in un DB:

• Alcuni diminuzione della complessità in quanto la strato di accesso ai dati del sistema di necessità interfacciarsi solo per un DB e non un DB + file system.
• È possibile proteggere i file utilizzando il stessi completi di autorizzazioni basate su di sicurezza che protegge il resto il database.
• I file binari sono protetti contro la perdita insieme al resto del i dati a titolo di backup dei database. Nessun sistema di backup del file system separato richiesto.

Contro di memorizzare i file binari in un DB:

• A seconda delle dimensioni / numero di file, può occupare spazio significativo potenzialmente diminuire le prestazioni (Dipendente dalla se il binario file sono memorizzati in una tabella che è interrogato per altri contenuti spesso o no) e facendo per il backup più volte.

A favore di memorizzazione file binari nel sistema di file:

• Questo è ciò che i file sistemi sono buoni a. I file system gestirà deframmentazione bene e il recupero file (dicono per lo streaming di un file video da attraverso un server web) sarà probabilmente più veloce che con un db.

Contro di memorizzare file binari nel sistema di file:

• accesso ai dati leggermente più complesso strato. Ha bisogno di un proprio sistema di backup. Necessità di prendere in considerazione referenziale problemi di integrità (per esempio cancellati puntatore nella banca dati sarà necessario comporterà la cancellazione di file in modo tale da non ha i file 'orfani' nella filesystem).

A conti fatti vorrei utilizzare il file system. In passato, l'utilizzo di SQL Server 2005 Vorrei semplicemente memorizzare un 'puntatore' nelle tabelle db al file binario. Il puntatore sarebbe tipicamente un GUID.

Ecco la buona notizia se si utilizza SQL Server 2008 (e forse altri - non so): v'è un supporto incorporato per una soluzione ibrida con il nuovo varbinary (max) tipo di dati FILESTREAM. Questi si comportano come logicamente varbinary (max) colonne, ma dietro le quinte, SQL Sever 2008 sarà memorizzare i dati nel file system.

Answer 3

Non c'è modo migliore.

Che cosa? Avete bisogno di ulteriori informazioni?

Ci sono tre modi che conosco ... uno, come array di byte nel database. Due, come un file con il percorso memorizzato nel database. Tre, come un ibrido (solo se DB permette, come ad esempio con la FileStream tipo).

Il primo è piuttosto fresco perché è possibile interrogare e ottenere i dati nella stessa fase. Che è sempre bello. Ma cosa succede quando si hanno un sacco di file? Il database diventa grande. Ora avete a che fare con grandi problemi di manutenzione del database, come ad esempio le prove di backup di database che sono più di un terabyte. E cosa succede se avete bisogno di accesso esterno per i file? Come ad esempio conversioni di tipo, manipolazione di massa (ridimensionare tutte le immagini, filigrane Appy, ecc)? La sua molto più difficile da fare che quando si dispone di file.

Il secondo è l'ideale per un po 'gran numero di file. È possibile memorizzare su dispositivi NAS, farne un backup incrementale, mantenere il database piccolo, etc etc. Ma poi, quando hai un sacco di file, si inizia a correre in limitazioni nel file system. E se li diffondere attraverso la rete, si ottiene problemi di latenza, le questioni dei diritti degli utenti, ecc Inoltre, ho avuto pietà di te se la rete viene risistemato. Ora si deve eseguire massicci aggiornamenti sul database di cambiare le posizioni dei file, e mi fai pena se qualcosa viti in su.

Poi c'è la scelta ibrida. La sua quasi perfetta - è possibile ottenere i file tramite la tua ricerca, ma il database non è enorme. Questo risolve tutti i vostri problemi? Probabilmente no. Il database non è più portatile; sei bloccato a un particolare DBMS. E questa roba non è maturo ancora, quindi si arriva a godere il processo di dentizione. E chi dice che questo risolve tutti i vari problemi?

Il fatto è, non esiste un modo "migliore". Devi solo per determinare i requisiti, a fare la scelta migliore a seconda della loro, e poi aspirare quando a capire che hai fatto la cosa sbagliata.

Answer 4

Mi piace la memorizzazione di immagini in una database . Lo rende facile passare dallo sviluppo alla produzione semplicemente cambiando banche dati (non la copia di file). E il database può tenere traccia di immobili come create date / modificati altrettanto bene come il File System.

Answer 5

Personalmente non ho mai memorizzare le immagini nel database per il calcolo delle prestazioni. In tutti i miei siti Ho una cartella "/ files" dove posso mettere sotto-cartelle in base al tipo di immagini ho intenzione di negozio. Poi li ho nome sulla convenzione.

Per esempio se io sono la memorizzazione di una foto del profilo, ho Sarà memorizzare in "/ files / profile /" come profile_2.jpg (se 2 è l'ID dell'account). Ho sempre fare una regola per ridimensionare l'immagine sul server per la dimensione più grande avrò bisogno, e quelli più piccoli poi se ne ho bisogno. Così mi piacerebbe risparmiare "profile_2_thumb.jpg" e "profile_2_full.jpg".

Con la creazione di regole per te si può semplicemente nel src codice di chiamata img = "/ files / profile__thumb.jpg"

thats come lo faccio comunque!