Andreas: Dateien in DB verschlüsselt ablegen und wieder abrufen

Beitrag lesen

Hallo Cruz,

Dann kann ich allerdings deine Entscheidung für das HTML Formular nicht nachvollziehen. Vielleicht hast du noch nicht alles erzählt, was du mit dieser File-Datenbank machen möchtest. Ein HTML Frontend eignet sich dann besonders gut, wenn du die Absicht hast die Software aus dem Internet oder zumindest aus einem LAN zu nutzen. Für eine Einzelstationsanwendung eignet sich HTML in MHO nicht besonders gut, da man z.B. die ganzen Schwächen des stateless HTTP Protokolls bekämpfen muss.

Stimmt auch wieder. Was ich mir halt dazu noch basteln möchte ist ein Frontend, so dass ich lokal per Browser die Dateien auch verwalten, suchen und abrufen kann.

Schon alleine der Upload ist ein Umweg von hinten durch die Nase ins Auge. Die Datei muss über ein Klartextprotokoll codiert werden und wird auch noch mit Zeug drum herum eingepackt (Header und so ein Kram) nur um dann später wieder ausgepackt, decodiert und in die Datenbank geschrieben zu werden. Der direkte Weg ohne HTTP dazwischen ist kürzer und einfacher.

Da dies sowieso nur lokal läuft, sehe ich die Übertragung im Klartext nicht schlimm an. Aber ist sicher ein Argument.

Hm Transaktionssicherheit? Ok was bedeutet das eigentlich genau? Meines Wissens nach ist eine Art alles oder nichts Verhalten, also mehrere zusammenhängende Datensätze werden nur in ihrer Gesamtheit geschrieben bzw. gelöscht, die Datenbank macht keine halben sachen.

Genau. Mit den InnoDB Tabellentypen geht das zum Beispiel auch. Ich glaube diesen Tabellentyp gibt es schon relativ lange.
Außerdem muss ich so nur überprüfen, ob die insert´s alle korrekt ausgeführt wurden und muss mich nicht darum kümmern, ob auch die Datei im Filesystem gelandet ist, falls ich alles in die DB ablege.

Und du kannst einen Rollback machen. Solange du nur eine Tabelle hast, kannst du mit Transaktionssicherheit nichts anfangen.

Es gibt ja noch eine Tabelle mit den Metaangaben (id,metaangabe), sowie eine Tabelle für die Zuordnung "Metaangabe zur Datei" (metangabe_id,datei_id). Daher macht das schon etwas Sinn mit der Transaktionsicherheit. Ok, ich gebe zu: Als lokale Einzelanwendung sicher etwas übertrieben ;-)

Wenn du die Files in die Datenbank schreibst, dann sind sie auch von der Datenbank abhängig, denn du kommst nicht an die Dateien dran ohne die Datenbank zu konsultieren. Was ist wenn das gerade mal aus irgendwelchen Gründen nicht geht, aber du willst schnell mal an eine Datei ran? Oder bedenke wie es ausschaut, wenn du die Datenbank administrierst und z.B. über einen Dump die Daten verschieben willst. Dann stehen die ganzen verschlüsselten Files in einer riesigen Textdatei, das ist doch irgendwie krumm. Oder wie realisierst du einen Backup? Sind die verschlü. Files im Filesystem, stehen dir alle Backuptechnologien der Welt zur Verfügung. Sind die Files in der Datenbank, musst du sie entweder erst dumpen und dann sind wir wieder bei der schrägen Textdatei, oder du musst halt die ganze Datenbank auf Filesystemebene backupen und verschwendest damit Platz.

Ich sichere (fast) täglich die relevanten Daten vom Rechner. Dazu gehören unter anderem auch alle Datenbanken und das htdocs Verzeichnis. Also das ist nicht weiter problematisch und erfordert keinen weiteren Aufwand. Und so groß werden die Daten auch nicht. Vornehmlich sollen da einige wenige private Dokumente abgespeichert werden. So wie es aussieht wird kaum eine Datei größer als 1MB groß.

So jetzt habe ich also ganz klar die Position "Files ins Filesystem" bezogen und ein paar Argumente gebracht, würde aber allerdings gerne auch Argumente für die Gegenseite hören. Auch wenn das jetzt keine mission critical Anwendung werden soll, macht es doch Spaß sich die Pros und Kontras zu überlegen. Ich will dich auch nicht beim brechen und biegen davon abbringen die Files in die DB zu schreiben, ich bin eher an der Diskussion interessiert. :)

Ich ebenso :-) Und wie gesagt ist es eh für den privaten Einsatz gedacht. Und was mir auch wichtig ist, wie "sicher" man dieses Vorhaben umsetzen kann. Da weiss ich leider nicht genau Bescheid, ob das mySQL DECODE hinreichend sicher ist und was man anschließend shredden sollte.

Viele Grüße
Andreas