Hochgeladene Dateien im ASCII-Format in einer DB speichern

[Alexander (HH)]

Moin Moin!

Hallo Mitstreiter,

siehe Thema. Max_Size ist 0.7 MB/File.

Wer garantiert diese Maximalgröße?

Die Dateien werden im ASCII-Zeichensatz (Base64_encode, _decode) in ein Textfeld geschrieben. Damit bin ich unabhängig vom verwendeteten Zeichensatz, den die RDMS spricht (in meinem Fall mySQL).

Und Du hast 33% Overhead.

Ein Kollege indes warnte mich davor, Dateien in der DB selbst zu speichern. Begründen konnte er das jedoch nicht.

Spricht nicht gerade für Unmengen an Kompetenz und Motivation.

Hier mal die Vorteile, die ich sehe:

• konsistente Datenhaltung ohne Medienbrüche zwischen Filesystem und DB,

Richtig.

• in der DB stehen fakultative Angaben zur Datei, wie z.B. eine Beschreibung,

Das ist unabhängig davon, wo die Datei liegt.

• Weitere Felder eines Records sind: Content-type, size,

Ditto.

Übrigens: Woher kommt der Content-Type? Glaubst Du dem hochladenden HTTP-Client?

• da die Dateien Base64 codiert und der Content-Type gespeichert sind, wird das automatisierte Erstellen von Mails vereinfacht,

Aber das Ausliefern der uncodierten Datei wird erschwert, weil Du einen Durchlauf vom Base64-Decoder brauchst.

• ebenso ist es für die Anwendung einfach, den für den Content-Type richtigen Header zusammenzubauen und die Datei zum Browser zu schicken,

Auch das hat mit der Lage der Datei nichts zu tun.

• Suchmöglichkeit in der DB.

Nur über die Metadaten. Im Base64 wirst Du nicht sinnvoll suchen können, ohne in der DB die Daten zu decodieren.

Hier mache ich mal einen Punkt und bitte Euch, ein paar Nachteile dieser Diät zusammenzutragen.

Dein Dateisystem bleibt schlank, aber die DB wird richtig fett.

Übrigens hat MySQL auch Datentypen, um mit Binärdaten zu arbeiten, ohne die 33% Overhead von Base64. Im Gegensatz zu anderen RDBMS lassen die sich ohne viel Theater mit SELECT, INSERT und UPDATE behandeln.

Alexander