PDF auf Mysql oder Mssql

[bjma]

Guten Tag,

ich habe im Forum schon viele Details zu diesem Thema gelesen.
Richtig schlau bin ich aber dadurch nicht geworden.

Ich soll für ca. 100.000 PDf Dokumente eine Datenbank anlegen.
Entweder Mysql oder Mssql.
Die Dokumente liegen auf dem Server in einem Verzeichnis und sollen in die Datenbank übernommen werden.

In dieser Datenbank sollen die PDF-Dokumente teilweise bis zu 5 Seiten eingestellt werden.
Durchschnittlich 280kb je Dokument.
Die Dokumente sollen über ein Blobfeld verwaltet werden.
Tabelle enthält weiterhin Datum,Id,Berechtigung usw.

Erste Frage:
Ist die Performance überhaupt ausreichend für dieses Vorhaben.
Oder gibt es bessere Möglichkeiten.

Zweite Frage:
Wie bringe ich die PDF's in die Datenbank. Die Beispiele im Forum haben mich etwas verwirrt.
Gibt es fertige Tools für eine einfache Dokumentenverwaltung.


Wäre super hier genauere Angaben zu erhalten.

Gruß Jürgen :oops:

[mkinzler]

Grundsätzlich sollten beide DBMS für diese Aufgabe geeignet sein.

https://www.bitfarm-archiv.de/downloads-support/

(Ist in Delphi geschrieben, Quellcode verfügbar)

[Schokohase]

Können kann das quasi jedes Datenbanksystem.

Einige bieten dafür spezielle Techniken an FILESTREAM (SQL-Server)

[KodeZwerg]

Zitat:

Zitat von bjma (Beitrag 1406568)

Zweite Frage:
Wie bringe ich die PDF's in die Datenbank. Die Beispiele im Forum haben mich etwas verwirrt.
Gibt es fertige Tools für eine einfache Dokumentenverwaltung.

Anzeigen würde ich es so:
Blob/PDF in ein Memorystream laden und mit einer geeigneten PDF Komponente die Memorystreams unterstützt wiedergeben.
WPViewPDF kann das und Verwaltet wird es durch Dich/Deiner DB.

[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..

[TigerLilly]

Zitat:

Ist die Performance überhaupt ausreichend für dieses Vorhaben.

"Performance" setzt sich aus vielen Faktoren zusammen. Der Erste ist: Was soll denn überhaupt passieren, wenn die PDFs in der DB sind. Dann kommt die Hardware + das Netzwerk. Aber grundsätzlich geht das + ist kein Problem + sowohl MySQL als auch MSSQL schaffen das mit Links.

Zitat:

Wie bringe ich die PDF's in die Datenbank. Die Beispiele im Forum haben mich etwas verwirrt.

https://stackoverflow.com/questions/...-in-a-database
https://www.128byte.ru/index.php?id=46
http://edn.embarcadero.com/article/27462

[KodeZwerg]

Zitat:

Zitat von jobo (Beitrag 1406590)

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:

Zitat von hstreicher (Beitrag 1406632)

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:

Zitat von KodeZwerg (Beitrag 1406625)

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.

[TigerLilly]

Zitat:

Zitat von p80286 (Beitrag 1406643)

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.

Nein, das sollte man so nicht sagen. Ein Filesystem ist doch auch nichts anderes als eine Datenbank. Selbstverständlich kann man in eine Datenbank alles hineinstopfen, wozu man Lust hat. Wie gut das geht + wie effektiv dann der Zugriff darauf ist, macht die Qualität einer Datenbank aus. Und von "Datenbank" zu reden, ist per se schon nicht zulässig, denn das schließt BigData-DBs, NoSQL-DBs, SQL-DBs und was es sonst noch gibt (embedded, lokal!) mit ein.

[Schokohase]

Filesystem = Datenbank - also das ist mehr ein Key-Value-Store als eine Datenbank, aber ja, speichern kann man überall etwas.

[jobo]

Zitat:

Zitat von TigerLilly (Beitrag 1406670)

Zitat:

Zitat von p80286 (Beitrag 1406643)

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.

Nein, das sollte man so nicht sagen. Ein Filesystem ist doch auch nichts anderes als eine Datenbank. Selbstverständlich kann man in eine Datenbank alles hineinstopfen, wozu man Lust hat. Wie gut das geht + wie effektiv dann der Zugriff darauf ist, macht die Qualität einer Datenbank aus. Und von "Datenbank" zu reden, ist per se schon nicht zulässig, denn das schließt BigData-DBs, NoSQL-DBs, SQL-DBs und was es sonst noch gibt (embedded, lokal!) mit ein.

Ich finde, das kann man schon so sagen. In diesem Thread redet der TE ja nicht von irgendeiner Datenbank im Allgemeinen, sondern von 2 konkreten Produkten der Gattung RDBMS. Überhaupt wird im Kontext von Delphi hier im Forum sehr häufig von RDBMS und nicht von NoSQL usw. geredet, wenn es auch oft einfach nur "Datenbank" genannt wird. Das ist ein Unterschied!
Bspw. ganz brandneu MongoDB 4.0 ".. jetzt mit Transaktionen..". Man lese und staune! RDBMS -die "Datenbanken" von denen wir hier meist reden- machen das seit mittlerweile Jahrzehnten. Bedeutet nicht, dass das per se besser ist. Besser ist es nur, wenn man es braucht, denn es kostet (auch bei kostenlosen RDBMS) ...
Aber hatten wir ja schon alles.

[Delphi.Narium]

Zitat:

Zitat von jobo (Beitrag 1406669)

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.)

[bjma]

Danke für die vielen Tipps.
Ich probiere gerade verschiedene Anregungen aus.
Danach melde ich mich nochmals.

Ihr habt mir sehr geholfen.

Gruß Jürgen

[bjma]

Danke für Eure Hilfe.
Ich habe mich für die Speicherung der Pdf's im mysqlserver entschieden.
So nun muß ich die einzelne Pdf hochladen.

Meine Tabelle heißt: Dokument_pdf
Das Blobfeld in der Tabelle: pdf_form

Dies habe ich folgendermaßen versucht:

procedure pdf_save_toserver;
var
blobfield:tfield;
bs:tstream;
begin
with Dokument_pdf do
begin
insert;
blobfield:=fieldbyname('PDF_form');
bs:=createblobstream(blobfield,bmwrite);
Bitmap.savetostream(bs);
post;
end;

end.

Fehlermeldung: Undeklarierter Bezeichner savetostream

Ich habe mir die Procedure abgeschaut und es fehlt wahrscheinlich eine Function.

Wer kann mir weiterhelfen?

Danke für Antworten.

Jürgen

[Delphi.Narium]

Was bitte hat

Delphi-Quellcode:

Bitmap

in dem Quelltext zu suchen? Copy&Paste-Überbleibsel? ;-)

Nimm bitte das with aus dem Quelltext heraus, dann wird es lesbarer und die Chancen auf Fehlinterpretationen seitens des Compilers sinken deutlich und die Fehlererkennungsrate steigt.

Mir ist z. B. nicht klar, warum savetostream nicht erkannt wird, aber Bitmap. Ist Bitmap nun ein Attribut von Dokument_pdf oder gibt es zufällig irgendeine Komponente namens Bitmap irgendwo im Quelltext oder ist eine Unit mit dem Namen Bitmap eingebunden?

Fehlermeldungen im Umfeld von with können zuweilen extrem verwirrend sein und einen auf eine vollkommen falsche Spur zur Fehlersuche führen.

[TRomano]

Hallo,

abgesehen von der wahrscheinliche ungültigen und unsinnigen Variable 'Bitmap' ist TStream eine abstrakte Klasse und besitzt keine Methode 'LoadFromFile'.

Delphi-Quellcode:

procedure LoadPDF;
var lBlobField  : TBlobField;
    lBlob       : TBlobStream;
    lFileStream : TFileStream:
begin
  lBlobField := TBlobField(DataSet.FieldByName('BLOB_X'));
  lBlob      := Dataset.CreateBlobStream(lBlobField, bmWrite);
  Dataset.Insert;
  try
    lBlob.Seek(0, soFromBeginning);
    lFileStream := TFileStream.Create('your.pdf', fmOpenRead or fmShareDenyWrite);
    try
      lBlob.CopyFrom(lFileStream , lFileStream .Size);
      Dataset.Post;
    finally
      lFileStream.Free
    end;
  finally
    lFileStream.Free
  end;
end;

Ist nur schnell runter geschrieben, da gerade kein Delphi zur Hand und ohne zu Testen. Ging nur um die Veranschaulichung des Vorgehens.
In einer normalen, ausgetesteten Methode würde ich noch das Dataset.Post per try ... except ... end absichern.