Dateien (z.B. PDFs) in SQL-Datenbank ablegen

de-users
#1

Hallo zusammen,

ich habe mir ein sog. "Raumbuch" programmiert. Hier kann ich für ein Bestandsgebäude zu jedem Raum Eigenschaften (Boden, Wand, Decke, Heizkörper etc.) hinterlegen. Auch Fotos habe ich bereits integriert.
Jetzt würde ich noch gerne Dokumente (z.B. Rechnung des Bodenlegers, Gebrauchsanweisung eines Heizkessels oder Zeichnungen) als PDF hinterlegen. Kann ich die als Datei direkt in die Datenbank speichern lassen (mir scheint: "nein"). Oder gibt es eine Chance, wenigstens eine URL zu speichern? Dies sollte aber nicht per Eintippen oder Kopieren aus dem Explorer erfolgen, sondern indem ein "Öffnen"-Dialog erscheint und man so die Datei auswählen kann. Später möchte ich sie natürlich durch Anklicken in der Tabelle wieder öffnen können. Klingt erst mal nicht zu kompliziert (da es ja mit Bilddateien geht). Die Bordmittel dafür scheinen allerdings zu fehlen...

Gruß,

Björn Schreiter - schreiter@schreiter-architekten.de
                                                                                                                                                                  
schreiter architekten lange straße 81a 44532 lünen fon 02306.37340-00 fax 02306.37340-10 www.schreiter-architekten.de

#2

Björn Schreiter schrieb:

Hallo zusammen,

ich habe mir ein sog. "Raumbuch" programmiert. Hier kann ich für ein Bestandsgebäude zu jedem Raum Eigenschaften (Boden, Wand, Decke, Heizkörper etc.) hinterlegen. Auch Fotos habe ich bereits integriert.
Jetzt würde ich noch gerne Dokumente (z.B. Rechnung des Bodenlegers, Gebrauchsanweisung eines Heizkessels oder Zeichnungen) als PDF hinterlegen. Kann ich die als Datei direkt in die Datenbank speichern lassen (mir scheint: "nein"). Oder gibt es eine Chance, wenigstens eine URL zu speichern? Dies sollte aber nicht per Eintippen oder Kopieren aus dem Explorer erfolgen, sondern indem ein "Öffnen"-Dialog erscheint und man so die Datei auswählen kann. Später möchte ich sie natürlich durch Anklicken in der Tabelle wieder öffnen können. Klingt erst mal nicht zu kompliziert (da es ja mit Bilddateien geht). Die Bordmittel dafür scheinen allerdings zu fehlen...

Gruß,

Björn Schreiter - schreiter@schreiter-architekten.de
                                                                                                                                                                  
schreiter architekten lange straße 81a 44532 lünen fon 02306.37340-00 fax 02306.37340-10 www.schreiter-architekten.de

Hallo,
zunächst würde ich persönlich Dateien nicht in der Datenbank ablegen.
Je nachdem wieviele Projekt Du hast und wieviele Leute damit arbeiten
könnte die DB schnell riesig werden..
Den Vorgang mit der URL müsstest Du halt als Makro realisieren.
Und den Pfad dorthin in einer eigenen Tabelle hinterlegen.

Ich denke gerade über ein ähnliches Projekt nach, da gehts um
Hotelrenovierungen. Könnte ich mal eine Kopie Deines Raumbuches haben?

#3

Hallo Björn,

grundsätzlich geht das, dazu kannst Du den MySQL Datentyp BLOB benutzen.
Allerdings benötigst Du eine Client-Applikation, die Dein PDF in ein
solches BLOB speichert. Hast Du Dein Raumbuch mit Base gemacht? Base
scheint da nur Bilder zuzulassen. Das würde ich mal als Fehler an die
Entwickler melden. Grundsätzlich kann in ein binäres Datenfeld jeder
beliebige Inhalt eingefügt werden. Man müsste dann allerdings auch
festlegen können, mit welchem Viewer man das jeweilige Feld darstellen
kann, wenn man es dann wieder lesen will.

Viel Erfolg.

Ulrich

#4

Hallo Björn,

Jetzt würde ich noch gerne Dokumente (z.B. Rechnung des
Bodenlegers, Gebrauchsanweisung eines Heizkessels oder Zeichnungen)
als PDF hinterlegen. Kann ich die als Datei direkt in die Datenbank
speichern lassen (mir scheint: "nein"). Oder gibt es eine Chance,
wenigstens eine URL zu speichern? Dies sollte aber nicht per
Eintippen oder Kopieren aus dem Explorer erfolgen, sondern indem ein
"Öffnen"-Dialog erscheint und man so die Datei auswählen kann. Später
möchte ich sie natürlich durch Anklicken in der Tabelle wieder öffnen
können. Klingt erst mal nicht zu kompliziert (da es ja mit
Bilddateien geht). Die Bordmittel dafür scheinen allerdings zu
fehlen...

Schau Dir einmal die Beispieldatenbanken zum neuen Handbuch an, Habe ich
heute gerade hochgeladen:
https://wiki.documentfoundation.org/images/2/23/BeispielDBs_mit_Beschreibung_V44.zip

Das komplette neue Handbuch gibt es hier:
http://de.libreoffice.org/get-help/documentation/

Was Du brauchst ist die Datenbank, die sich mit der Einbindung von
Bildern auseinandersetzt. Das Verfahren ist vom Prinzip her gleich. In
dem Formular Pfadeingabe_Tabellenkontrollfeld_Pfadangabe gibt es so ein
Beispiel, bei dem jede außenstehende Datei über ein Dateiauswahlfeld vom
Pfad her in die Datenbank übertragen wird. Durch einen Klick auf einen
Button wird die Datei mit dem Programm geöffnet, das in der
Benutzeroberfläche Deines Betriebssystems mit der Dateiendung verbunden ist.
Auch Bilder würde ich so aufnehmen und nicht in die Datenbank selbst
einlesen. Die wird sonst irgendwann viel zu groß.

Gruß

Robert

#5

Noch eine Anmerkung zu der Aussage, die Datenbank wird sonst viel zu
groß. Bei Bildern hängt die Größe natürlich stark von der Auflösung und
dem hoffentlich gewählten Kompressionsverfahren ab. PDF-Dateien hingegen
sind relativ klein, wenn es echte PDFs sind und nicht ein PDF-Frame mit
eingebetteten TIFF-/JPEG-/PNG-Bildern. Hinsichtlich der Größe muss man
bedenken, dass alle BLOB- und TEXT-Daten in MySQL immer in Chunks von 2,
4 oder 8 KB größe angelegt werden, je nachdem welchen BLOB- oder
TEXT-Typ man wählt.

Aber zur Größe ein kleines Beispiel. In einem Projekt, in dem Metadaten
und die Originaldaten transaktionsgesichert in einer Datenbank
gespeichert werden mussten, habe ich ca. 200000 Dokumente mit geschätzt
1 Millionen Seiten in einer Datenbank gespeichert. Der größte Teil waren
echte PDFs generiert aus Office, mit Acrobat oder irgendwelchen PDF
Druckertreibern. Die Datenbank hatte am Ende ein Größe von ca. 10GB und
das ist nichts für eine MySQL DB. Es sollte dann aber eine InnoDB
Instanz sein oder Du musst die BLOBs in eine per eindeutigem Schlüssel
verknüpfte separate Tabelle legen und nie SELECT * verwenden.

Gruß

Ulrich

#6

Hallo Ulrich,

Noch eine Anmerkung zu der Aussage, die Datenbank wird sonst viel zu
groß. Bei Bildern hängt die Größe natürlich stark von der Auflösung und
dem hoffentlich gewählten Kompressionsverfahren ab. PDF-Dateien hingegen
sind relativ klein, wenn es echte PDFs sind und nicht ein PDF-Frame mit
eingebetteten TIFF-/JPEG-/PNG-Bildern. Hinsichtlich der Größe muss man
bedenken, dass alle BLOB- und TEXT-Daten in MySQL immer in Chunks von 2,
4 oder 8 KB größe angelegt werden, je nachdem welchen BLOB- oder
TEXT-Typ man wählt.

Berücksichtige bitte, dass Björn mit keinem Wort erwähnt hat, dass er
mit einer externen Datenbank arbeitet. Und die interne HSQLDB-Datenbank
wird mit der *.odb-Datei gespeichert. 10 MB wäre mir da doch von der
Größe her recht kritisch.

*.pdf-Dateien sind häufig nicht nur Text. Nun ist so etwas wie ein
Handbuch eine Ausnahme, aber das neueste Base-Handbuch hat in der
*.pdf-Fassung bereits über 10 MB (und ist in der *.odt-Fassung noch
etwas größer als 11 MB).

Kommt als nächstes hinzu, dass die Bordmittel auch erst einmal keine
Möglichkeit bereitstellen, an die intern gespeicherten Bilder oder auch
sonstige Dateien wieder ran zu kommen.

Da habe ich die Dokumente doch lieber gut sichtbar in einem separaten
Verzeichnis liegen, wo sie auch verfügbar sind.

Gruß

Robert

#7

Hallo Robert,

Hallo Ulrich,

Noch eine Anmerkung zu der Aussage, die Datenbank wird sonst viel zu
groß. Bei Bildern hängt die Größe natürlich stark von der Auflösung und
dem hoffentlich gewählten Kompressionsverfahren ab. PDF-Dateien hingegen
sind relativ klein, wenn es echte PDFs sind und nicht ein PDF-Frame mit
eingebetteten TIFF-/JPEG-/PNG-Bildern. Hinsichtlich der Größe muss man
bedenken, dass alle BLOB- und TEXT-Daten in MySQL immer in Chunks von 2,
4 oder 8 KB größe angelegt werden, je nachdem welchen BLOB- oder
TEXT-Typ man wählt.

Berücksichtige bitte, dass Björn mit keinem Wort erwähnt hat, dass er
mit einer externen Datenbank arbeitet. Und die interne HSQLDB-Datenbank
wird mit der *.odb-Datei gespeichert. 10 MB wäre mir da doch von der
Größe her recht kritisch.

stimmt, ich hatte es übersehen, dass da ja nur SQL stand und damit
wahrscheinlich die interne DB gemeint ist. Aber soweit ich weiß
verwendet HSQLDB auch die erwähnten Chunks.

*.pdf-Dateien sind häufig nicht nur Text. Nun ist so etwas wie ein
Handbuch eine Ausnahme, aber das neueste Base-Handbuch hat in der
*.pdf-Fassung bereits über 10 MB (und ist in der *.odt-Fassung noch
etwas größer als 11 MB).

Wenn ich Björn richtig verstanden habe, dann sind seine Dokumente
wesentlich kleiner.

Kommt als nächstes hinzu, dass die Bordmittel auch erst einmal keine
Möglichkeit bereitstellen, an die intern gespeicherten Bilder oder auch
sonstige Dateien wieder ran zu kommen.

Da habe ich die Dokumente doch lieber gut sichtbar in einem separaten
Verzeichnis liegen, wo sie auch verfügbar sind.

Für den Fall, dass man keine Transaktionssicherheit und keine gesicherte
referenzielle Integrität zwischen Metadaten und Bildern und Dokumenten
braucht ist eine externe Speicherung sicherlich eine akzeptable
Alternative. In meinem Fall musste sichergestellt werden, dass kein DAU
evtl. eine Dokumentendatei löscht, auf die in der Datenbank verwiesen
wird. Hier waren externe Regulatoren involviert, die in einem solchen
Fall, dass die Datenintegrität verletzt werden kann, teilweise
empfindliche Strafen verhängen können.