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

[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 von bjma:

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