PDF auf Mysql oder Mssql

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

[TigerLilly]

Zitat von p80286:

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 von TigerLilly:

Zitat von p80286:

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

[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