Um einen Blob zu verwenden oder nicht (mysql + coldfusion)

Question

Ich würde gerne wissen, ob es eine gute langfristige Idee ist, PDFs in einer Datenbanktabelle zu speichern. Hier ist eine Beschreibung des Problems:

Ich habe einen Kunden, der Hunderte von Kunden hat, die zahlreiche PDF-Dateien als Nachweise hochladen. Diese PDF-Dateien reichen von recht klein (< 100K) bis zu 10 MB. Diese Dateien können potenziell mehrmals hochgeladen werden, da es sich um Nachweise für ein einziges Projekt handelt (z. B. proof1.pdf, proof2.pdf usw.). PDFs für jeden Kunden müssen getrennt bleiben, und PDFs für jedes Projekt müssen für jeden Kunden getrennt bleiben.

Aktuell ist es so eingerichtet, dass die Dateien direkt in einen für jeden Kunden und jedes Projekt erstellten Ordner hochgeladen werden. Das ist in Ordnung, aber es benötigt Platz und das Auffinden von Dateien kann etwas problematisch sein. Wie gesagt, es werden mehrere Nachweise für jedes Projekt und jeden Kunden hochgeladen.

Die beste Lösung, die mir einfällt, ist, eine Benutzeroberfläche bereitzustellen, die PDF-Dateien direkt in eine DB-Tabelle hochlädt, die die Kunden-ID, die Projekt-ID und den Nachweis speichert. Dies bietet eine viel bessere Sicherheit und die Möglichkeit, alle PDF-Dateien von jedem Kunden für Projekt X zu erhalten.

Ein Datenbankbereinigungstool wird entwickelt, um Datensätze zu löschen, die älter als einen bestimmten Zeitraum sind, damit die Tabelle nicht endlos wächst. Ich mache mir jedoch Sorgen über den Leistungsverlust (falls es einen gibt) und andere mögliche Nachteile, die ich übersehe.

Also, insgesamt ist dies eine gute Idee oder sollte ich einen besseren Weg finden, um damit im Dateisystem umzugehen?

Answer 1

Ich würde empfehlen, leichte Schlüssel zu speichern, die auf Daten in einem Dateisystem verweisen, anstatt die tatsächlichen Dateidaten in einem BLOB-Feld zu speichern. Eine mögliche Anordnung wäre, Ihre Dateien zu hashen (zum Beispiel mit SHA-1) und diesen Hash als Dateinamen auf der Festplatte zu verwenden - möglicherweise sogar die Speicherung in einen Verzeichnisbaum anzuordnen, der über die ersten n Hash-Zeichen abgebildet wird (d.h., 80cdef... könnte in storage/8/0/c/d/80cdef... gespeichert werden).

Ihre Tabelle könnte dann aus einem Primärschlüssel, einem benutzerfreundlichen Anzeigenamen für die Datei und einem Feld bestehen, das den (Hash-)Namen der physischen Datei auf der Festplatte enthält.

Dies ermöglicht es Ihnen auch, die Dateispeicherung vom Datenbankspeicher in zum Beispiel ein verteiltes Dateisystem zu trennen; dies wäre eine durchaus vernünftige Trennung in einem langfristigen System, das zwangsläufig sehr groß wird. Auf diese Weise behalten Sie die Vorteile einer relativ kleinen Datenbank (potenziell bessere Leistung und weniger Backup-Aufwand) bei, während Sie das schwierigere Problem der massiven Speicherung an ein System auslagern, das außerhalb der Datenbank selbst existiert und für das es bereits eine Vielzahl bewährter Ansätze gibt.

Answer 2

Ich neige dazu, mich davor zu scheuen, Dateien in Datenbanken zu speichern. Ich habe mit Blackboard-Installationen auf einem Campus gearbeitet und in dieser Anwendung können Dateien hochgeladen werden. Als Folge davon wuchs die Datenbank auf eine unverwaltbare Größe von über 1 TB. Blackboards Backup-System verpackte jeden Kurs als Zip-Datei und um ein vollständiges Backup eines Kurses durchzuführen, mussten alle Dateien herausgezogen und komprimiert werden... das wurde ein zeitaufwändiger Prozess. Wir mussten Backups regelmäßig aufteilen (und erneut aufteilen).

Hier ist ein weiterer Beitrag, der sich dazu äußert: Stackoverflow Beitrag