PDF auf Mysql oder Mssql

[jobo]

Ich weiß nicht, ob das eine gute Idee ist.
Es geht natürlich, alle Form von Binärdaten können in einer DB abgelegt werden.

Fachlich geht das aber am Nutzen einer DB vorbei und produziert eine Menge Overhead, der durch Hardware, Caching, .. "bekämpft" werden muss.

M.E. ist das primäre Interesse bei einer Dokumentenablage nicht, das Dokument selbst in der DB "sicher" abzulegen, sondern maximal dessen Metadaten. Also allerlei Dokumenteigenschaften, ggF. Textinhalt, Volltextindex, Bildquellen, Referenzen, ..

Was man natürlich vordergründig einfach erreicht, ist der Schutz des Dokuments selbst. (Eben zu einem relativ hohen Preis)
Diesen Schutz -sagen wir mal Zugriffs und Manipulationsschutz- kann man auch erreichen, indem man einen normalen Fileserver nimmt, dessen Zugriffsrechte nur dem DBServer oder einem zwischengeschalteten Applicationserver gegeben sind.

Klassischer Fall von / für Dokumentenmanagement-Systeme. Besonders dann, wenn es um Nachweispflichten etc. geht und man entssprechend zertifizierte DMS einsetzt.

Allein folgendes Gedankenexperiment macht vielleicht nachdenklich:
Die Transaktionssteuerung der DB, die Rollbackmöglichkeit, die inkludierte "Fehlertolleranz" erfordern es, alle Datenbewegungen zu loggen und vorwärts, rückwärts reproduzierbar zu machen. Bei normalen Datensätzen ist das kein Problem, bei dicken Binärdaten auch nicht, diese sind allerdings meist statisch, es wird ein Haufen Änderungen gechrieben wobei die Änderung selbst nur ein paar Byte beträgt. Ein PDF, was Du in die DB schickst, "vervielfacht" sich dabei aus Volumenperspektive u.U. bis hin zum stark vergrößerten Backupvolumen der DB. Eine Korrektur von ein paar Metadaten (in der gleichen Tabelle, in der das PDF liegt) erzeugt dann immer neue hohe Backupmengen.

[Delphi.Narium]

Zitat:

Tabelle enthält weiterhin Datum,Id,Berechtigung usw.

anlegen, plus Pfad und Dateiname zum PDF.

Die PDFs kommen auf eine "Festplatte" (Fileserver ... wie auch immer) und nur der DBServer bzw. der dort eingerichtete User für den Dateizugriff, darf auf die PDFs zugreifen.

Im Prinzip das, was Jobo auch beschreibt.

Alle (vermutlich) statischen PDFs jeden Tag (oder so) mit in die Datensicherung der Datenbank, erscheint mir übertrieben.

Eventuell beschreibst Du mal etwas genauer, um was für ein Umfeld es sich handelt und welcher konkreten Aufgabe die Datenbank dienen soll. Eventuell können wir da dann präzisere Vorschläge machen.

So nach dem Motto:

Daten sollen einfach nur leichter zugreifbar werden ...
PDFs sollen gezielter gesucht werden können ...
PDFs sollen nur über eine stringente Rechteverwaltung eingesehen werden können ...

...

[mkinzler]

Grundsätzlich würde ich Dokument auch mit in die DB aufnehmen. Es gibt natürluch auch Szenarien die dagegen sprechen.

[Bernhard Geyer]

Bei PDF ist es nicht so schwierig das in die DB zu bringen.
Bei Formaten (wie html) die aus mehr als eine Datei besteht ist es schon "heraufordenter" alle benötigten Dateien zu bestimmen.

[jobo]

Vielleicht noch als Ergänzung:
Gerade bei PDF wäre eine sinnvolle Funktionalität ja eine indizierte Suche.
Dazu müsste dann ein Textextract nach dem Upload angefertigt werden und in der DB in einem Textblob abgelegt werden.
Dann mittels DB Mechnismen (Index, Thesaurus, ..) eine intelligente, Dokument übergreifende Suche in der Anwendnung anbieten.

Gibt es auch schon fertig.

HTML oder andere Dateien, die zu mehreren zusammengehören, könnte man entweder als ZIP weiterverarbeiten oder eben doch wieder nur ein Upload in ein Serverdateisystem, dessen Ordner dann jeweils in der DB referenziert werden.

Hier gilt (wie fast immer) eine eigene Implentierung ist sinnvoll je nach Anforderung, Dateidetails. Nicht alles ist gut zu zippen..

[KodeZwerg]

Zitat von jobo:

Ich weiß nicht, ob das eine gute Idee ist.
Es geht natürlich, alle Form von Binärdaten können in einer DB abgelegt werden.

Fachlich geht das aber am Nutzen einer DB vorbei und produziert eine Menge Overhead, der durch Hardware, Caching, .. "bekämpft" werden muss.

Ich finde diese Aussage im Zusammenhang mit dem was der TE vorhat belanglos.
Eine Datenbank ist doch zum sammeln von Daten da, oder irre ich mich?
Ob die Daten nun Kontoauszüge Deiner Oma, Pläne zur Eroberung der Weltherrschaft oder PDF-Dokumente sind ist belanglos.
Ob ich Daten übers Netzwerk aus einer DB oder direkt von Datei in den Speicher lade ist für mich der gleiche Overhead, ok es werden bei DBs noch ein paar mehr Informationen mitgeschickt/gesendet, viele Pakete enthalten auch Quersummen damit Endstelle ein "Ok, hab korrektes Paket erhalten nun sende das nächste", aber das ist so marginal das es eigentlich nicht auffallen dürfte.
Ob die Quelladresse nun ein Fileserver DB-Server FTP-Server ist für mich ebenso belanglos, da egal was/woher - es wird lokal im Speicher gepuffert, jedenfalls bei den Methoden die ich für so etwas anwenden würde. Man kann natürlich um das ganze zu beschleunigen auch mit Chunks arbeiten, aber PDF intern wird erst am Ende der Übertragung ein ganzes daraus, rangepappte Medien ausgeschlossen, die sind optional.

[hstreicher]

Hier wurde das schon mal besprochen

https://www.delphipraxis.net/183571-...der-nicht.html

[p80286]

Zitat von hstreicher:

Hier wurde das schon mal besprochen

https://www.delphipraxis.net/183571-...der-nicht.html

Naja ist jetzt drei Jahre her. Ich für meine Person würde immer noch die externe Speicherung vorziehen, wenn sicher gestellt ist, das eine permanente Synchronisation zwischen internem und externen Speicher erfolgt.
Alles in eine Datenbank zu stopfen ist zwar teurer, erleichtert aber die Verwaltung. Insbesonders wenn das Management nicht nach fundierten IT-Kenntnissen ausgesucht wurde.

Zitat von KodeZwerg:

Eine Datenbank ist doch zum sammeln von Daten da, oder irre ich mich?

Jain. Eine Datenbank ist für die effiziente Verwaltung und Zurückholung von Daten entworfen worden. Einfach Daten in eine DB hinein stopfen und keine entsprechenden Beschreibungen hinzu zu fügen ist kontraproduktiv. Oder anders ausgedrückt, Datenbanken sind für die Verwaltung von Informationen gemacht, nicht für die Verwaltung von irgendwelchen anonymen (binären) Datensammlungen. Das kann z.B. ein Filesystem wesentlich effizienter.

Gruß
K-H

[jobo]

"belanglos"
tja, kann man so sehen, man kann auch genauer hinschauen, wie p80286.

Formal ist es belanglos, ob Adresse, PDF oder DVD ISO Images. Alles kann man speichern. Was ich dazu sage ist lediglich eine Kosten/Nutzen Bilanz. Hohe Kosten (Ressourcen>Hardware>Geld) gegen wenig Nutzen.
Ein RDBMS -auch wenn es heute gern anders (schmaler) gesehen wird- speichert nicht einfach nur Daten. Es bildet Relationen ab, es bietet Transkationssicherheit, es verwaltet konkurrierende Zugriffe, uvma. Und das macht es nicht einfach nur so, es garantiert diese Merkmale. Dafür zahlt man einen relativ hohen Preis. Wenn man IO eines Fileservers mit dem eines DB Servers vergleicht, wird man das sehen.
Was eine DB auszeichnet, ist die Arbeit mit strukturierten Daten. Das ist ziemlich das Gegenteil von einem PDF File. (Nahezu) alle Werkzeuge/Funktionalität in SQL lässt sich nicht auf Binäre Daten anwenden.

Ich halte ja auch niemand ab, die Idee so umzusetzen. Es sind nur ein paar Hintergründe, die man in Betracht ziehen kann.

Könnte man noch stundenlang diskutieren, jetzt muss ich aber erstmal mit dem Land Rover meine Tochter nebenan in den Kindergarten bringen.

[Delphi.Narium]

Zitat von jobo:

Könnte man noch stundenlang diskutieren, jetzt muss ich aber erstmal mit dem Land Rover meine Tochter nebenan in den Kindergarten bringen.

Wunderbar

Das zeigt genau den Irrsinn, den man bei einer unüberlegten Nutzung einer Datenbank (quasi auf teufelkommraus) "veranstaltet".

Es fehlen immernoch Informationen.

Sind es 100.000 PDFs und bleiben es 100.000 PDFs?
Kommen da täglich welche hinzu? (oder wie sonst gestalten sich Veränderungen in der Datenmenge?)
Werden sie geändert (alte Version raus, neu Version rein)?
Werden sie versioniert/historisiert vorgehalten?
Gibt es konkurrierende Zugriffe? (Wenn einer liest, darf kein anderer gleichzeitig lesen?) (oder sowas?)

Technisch gehen tut das alles, aber ist es auch sinnvoll oder gibt es bessere Lösungsmöglichkeiten. (Bessere impliziert hierbei auch preiswertere und/oder einfachere Lösungen, die mindestens den gleichen Anforderungen gerecht werden.)