Dove conservare i file?
La questione se archiviare o meno i file nel database deve essere considerata sotto diversi angoli:
-
Consistenza : l'archiviazione dei metadati e dei file (come BLOB) nel database assicura che ciò che appartiene insieme rimanga insieme. Nessuna paura di incoerenza se l'inserimento è interrotto, nessuna posizione di archiviazione separata da gestire con l'url assoluto o relativo nel database.
-
Praticità : puoi spostare / eseguire il backup / replicare / monitorare il tuo database se hai solo bisogno di utilizzare gli strumenti del database. Con file separati, devi organizzare tutte le operazioni. Non è necessariamente difficile, ma devi prenderti cura di esso.
-
Sicurezza : la maggior parte dei DBMS offre alcuni meccanismi di autorizzazione per l'accesso degli utenti e persino la crittografia, se necessario. Quindi avere il file nel DMBMS assicura che nessuno manometta i file e solo quelli che hanno i necessari privilegi di DB possono accedervi. Con file separati all'esterno del database, è molto più difficile organizzarlo (a meno che tu non sia su un server e i client non possano accedere direttamente alle cartelle).
-
Rendimento: questo è qualcosa che devi controllare attentamente con il DBMS che sceglierai: l'API per accedere ai BLOB potrebbe richiedere un sovraccarico per il trasferimento da / verso il database in pezzi più piccoli. Quindi è necessario fare attenzione a richiedere questo oggetto solo se necessario. Qui con i file nel file system, è più veloce accedere ai dati grezzi quando è necessario. Tuttavia con così tanti file, potrebbe essere necessario distribuirli su più cartelle, per non risentire delle prestazioni di ricerca di ogni nome di file in una directory enorme.
-
Risorse: se dovessi prendere in considerazione l'utilizzo di un database in memoria per accelerare il tuo lavoro "semantico" sui metadati, sarebbe molto costoso archiviare anche tutti i dati chiari in memoria. Lì, file separati potrebbero davvero essere di vantaggio.
Non sapendo cosa sta facendo esattamente la tua applicazione, non sarebbe saggio consigliarti fermamente in un modo o nell'altro.
Esempi di vita reale
- Nella mia azienda utilizziamo un enorme ERP. I record delle transazioni finanziarie nel database si riferiscono a documenti finanziari scansionati che sono memorizzati al di fuori del DB su un server di contenuti distinto. Il content server è una specie di server web, che memorizza localmente i file immagine (JPG, PDF, ...) nel suo file system locale. La sicurezza dell'accesso è organizzata tramite un complesso schema di convalida dell'URL.
- Un altro sistema memorizza i documenti scansionati per un'attività non coperta dall'ERP. Le immagini vengono memorizzate direttamente nel database.
Quindi, in pratica, entrambi gli approcci funzioneranno. Il primo è basato su prodotti software standard. Il secondo è stato sviluppato internamente. Dal punto di vista delle prestazioni, entrambi sono molto simili perché le immagini sono accessibili dal client (cioè il sovraccarico potenziale nella gestione BLOB sul lato DB, sono compensate dal sovraccarico di un ulteriore trasferimento con il server web aggiuntivo).
Relazionale o no?
Se diventi relazionale, potresti voler gestire:
- i record di file (ad esempio identificazione, alcuni metadati univoci e BLOB).
- le parole chiave (metadati + elenco filtrato di parole in testo semplice)
- l'associazione di parole chiave a record di file (molti a molti).
Non c'è dubbio che le prestazioni e la flessibilità saranno lì, perché la ricerca di chiavi, l'unione di più ricerche, ecc. è il core business di un RDBMS. Ma dovrai capire come strutturare al meglio i metadati.
Potresti anche optare per un NoSQL database. Sono più flessibili sulla struttura dei dati. Intuitivamente suggerirei di iniziare a dare un'occhiata ai database dei documenti. Se invece preferisci mantenere i file fuori dal database, potresti essere più interessato a un archivio di valori-chiave, o anche a un grande archivio di colonne se gestirai diversi tipi di parole chiave per diversi tipi di metadati.