No, archivia i file direttamente su un file system e salva i percorsi relativi . Questo ha diversi vantaggi:
- migrazione più veloce del database in quanto non contiene TB di dati,
- non essendo limitato direttamente dalla posizione dello spazio di archiviazione - devi semplicemente anteporre la radice al relativo percorso e lavorare con quello (servirlo ai client dell'applicazione),
- per alcune risorse, cache nativa HTTP grazie alle intestazioni
Last-Modified/ETag e If-Modified-Since/If-None-Match , risparmiando così risorse client 1 ,
- nel tuo caso semplifica l'implementazione dello streaming di contenuti - consentendo ai client dell'applicazione di recuperare sezioni dei file video, tagliando il file video e restituendo solo un intervallo di byte specifico dal server.
Con i file memorizzati sul filesystem è necessario assicurarsi che siano in una directory che è pubblicamente disponibile (dovrebbe essere, ovviamente). Quindi servi questi file direttamente dal filesystem dal loro percorso.
Supponiamo che la tua applicazione si trovi a /home/dyslexit/www , dove www è una directory disponibile pubblicamente dal browser. All'interno della directory www ne creeresti uno nuovo, es. uploads , che sarebbe anche disponibile al pubblico e utilizzato per archiviare i file. Se dovessi servire un file a un client dell'applicazione, sarebbe semplice come fornire un URI: https://domain.com/uploads/videos/my-video.mp4 , che verrebbe tradotto nel file /home/dyslexit/www/uploads/videos/my-video.mp4 sul server.
Tuttavia non è necessario copiare direttamente la struttura. Se è necessario, invece di servire direttamente i file da un HDD quando viene richiesto un file, è possibile inoltrare la richiesta a uno script controllando le autorizzazioni dell'utente richiedente, negando loro l'accesso nel caso in cui non fosse autorizzato ad accedere a una risorsa oa inoltrarla a il file si trova ovunque, rispettivamente.
1 Ovviamente questo può essere implementato anche se si archiviano file in un database ma richiedono un'ulteriore configurazione e una manipolazione personalizzata dell'intestazione. Quando si servono i file direttamente dal file system, questo è principalmente nativo.
In entrambi i casi, se il tuo obiettivo aziendale non è la memorizzazione di file, ad esempio la creazione di un sistema di archiviazione dati, ma è solo un effetto collaterale del business (supponiamo che tu desideri i video in un'applicazione simile a Facebook) ), la scelta migliore sarebbe probabilmente esternalizzare completamente lo storage di file a un sistema di terze parti dedicato a questa funzione, come Amazon S3.