PDF-Dokumente in eine Datenbank oder nicht

[Lemmy]

Zitat:

Zitat von RWarnecke (Beitrag 1287271)

Zitat:

Zitat von mm1256 (Beitrag 1287256)

Letzendlich ist es doch so, dass jede Variante ihre Vor- und Nachteile hat. ...., dann switcht man einfach um auf externe Dateien.

Mmh, darüber habe ich noch nicht so genau nachgedacht, das ja ein Switch zwischen Datenbank und Verzeichnis für die Ablage von PDF-Dokumenten recht einfach sein kann....

man sollte halt wirklich jeden Beitrag lesen, auch wenn es manchmal viele sind...

http://www.delphipraxis.net/1287207-post18.html

Zitat:

Zitat von RWarnecke (Beitrag 1287271)

Der Gedanke hat irgendwie Scharm, da muss ich mal weiter drüber nachdenken.

nicht nachdenken.. machen! :-)

[RWarnecke]

Zitat:

Zitat von DeddyH (Beitrag 1287272)

Zitat:

Zitat von RWarnecke (Beitrag 1287271)

Da habe ich Zugriff auf alle SQLServer Varianten, dass stellt ein Problem dar.

So krass würde ich das aber nicht ausdrücken :lol: (SCNR)

Das ist genauer gesagt das Action Pack von Microsoft. Ja, da habe ich ein wenig übertrieben, aber der SQLServer ist auf jedenfall dabei.

[RWarnecke]

Zitat:

Zitat von Lemmy (Beitrag 1287273)

Zitat:

Zitat von RWarnecke (Beitrag 1287271)

Zitat:

Zitat von mm1256 (Beitrag 1287256)

Letzendlich ist es doch so, dass jede Variante ihre Vor- und Nachteile hat. ...., dann switcht man einfach um auf externe Dateien.

Mmh, darüber habe ich noch nicht so genau nachgedacht, das ja ein Switch zwischen Datenbank und Verzeichnis für die Ablage von PDF-Dokumenten recht einfach sein kann....

man sollte halt wirklich jeden Beitrag lesen, auch wenn es manchmal viele sind...

http://www.delphipraxis.net/1287207-post18.html

Upps, den hatte ich irgendwie nur überflogen :oops: Aber ich gebe Dir recht, das Sir Rufo das gleiche nur in anderen Worten ausgedrückt hatte.

Zitat:

Zitat von Lemmy (Beitrag 1287273)

Zitat:

Zitat von RWarnecke (Beitrag 1287271)

Der Gedanke hat irgendwie Scharm, da muss ich mal weiter drüber nachdenken.

nicht nachdenken.. machen! :-)

Das ist auf jedenfall eine Variation, die weiter verfolgen werde.

[sh17]

So, da wir jetzt hier fertig sind..:duck: nochmal eine Anregung, die vielleicht etwas untergegangen ist.

Was haltet ihr auf Client-Seite von virtuellen Dateisystemen um die Dokumente bereitzustellen? Wie etwa Dokanx.
Das würde auch das "Problem" von Berhard mit seinen HTML/css Dateien klären. Ich glaube Docuware hat da auch etwas in der Art integriert.

[himitsu]

Zitat:

Zitat von mensch72 (Beitrag 1287214)

Zufällig habe ich vor 3Jahren eine ähnliche Lösung für einen Kleinbetrieb entwickelt.

Hier wurde vor paar Jahren auch zufällig alles umgebaut.

Früher alle Dateien in der Datenbank .... in einer einzigen Tabelle, die pg_largeobjects des Postgress, welche immer größer wurde.
Zusätzlich bestand aber noch die Anforderung, daß Dokumente (notfalls) auch ohne Programm zugreifbar sind und eventuell einzelne Dateitypen (nach Dateiinhalt und nicht nach FileFormat) auf einem revisionssicheren Laufwerk gespeichert werden können sollen, welches irgendwie was Steuerrechtliches war.

Nunja, hier läuft auch ein eigener AppServer, der via TCP/IP (DataSnap) die Dateien an die Clienten ausliefert. Die Verwaltungsdaten stehen natürlich dennoch in der Datenbank und nur die Datei liegt in den Verzeichnissen. (in einer optionalen Meta-Datei zu jedem Dokument dann noch so Sachen wie programmseitige Stempel, Marker oder Texte, welche auf das Dokument gelegt wurden)

Vorteil ist auch, daß Backupprogramme hier sehr leicht mit differenziellen/inkrementellen Backups arbeiten können, da sie nicht nur eine große Datenbankdatei vorfinden.



Schwierig bei einer DB-externen Speicherlösung ist nur, daß DB-interne Änderungen (z.B. in Triggern) nicht so einfach an das Dateisystem weitergegeben werden können.

[Sir Rufo]

Zum Thema Dokumenten-Daten und Stream: Die kann man auch trennen. Die Meta-Daten sind idR sehr schnell verfügbar und der Stream dauert manchmal etwas länger. Also trennt man das und stellt ein Sammelobjekt zusammen.

Dieses Sammelobjekt weiß dann genau Bescheid, ob die Daten verfügbar oder angefragt sind.

Delphi-Quellcode:

TDocumentViewModel = class
public
  property IsLoading : Boolean;
  property HasData : Boolean;
  property Data : TStream;
end;

Beim ersten Zugriff auf die Eigenschaft

Delphi-Quellcode:

Data

sorgt das ViewModel dafür, dass die Daten (im Thread) geladen werden und setzt die Eigenschaft

Delphi-Quellcode:

IsLoading

auf

Delphi-Quellcode:

true

. Auf der Anzeige kann man das durch diesen AniIndicator darstellen (der drehende Kreis).
Hat der Thread die Daten geholt, dann wird der Eigenschaft

Delphi-Quellcode:

Data

der Stream gegeben und

Delphi-Quellcode:

IsLoading

wird wieder auf

Delphi-Quellcode:

False

gesetzt.
Hat der Thread keine Daten heranschaffen können, setzt man einfach

Delphi-Quellcode:

HasData

auf

Delphi-Quellcode:

False

.

[vagtler]

Zitat:

Zitat von RWarnecke (Beitrag 1287274)

[...] Das ist genauer gesagt das Action Pack von Microsoft. Ja, da habe ich ein wenig übertrieben, aber der SQLServer ist auf jedenfall dabei.

Ich glaube, das war anders gemeint... :mrgreen:

[DeddyH]

Stimmt :mrgreen:

[Hansa]

Holger Klemt hat ja schon Recht. Im Prinzip gehört schon alles in die DB. Nur, ich habe hier folgenden Fall : 100 MB Datenbank mit Bewegungsdaten, die sich täglich ändern und deswegen imho täglich gesichert werden müssen. Dann sind da noch Daten von 10 GB, die sich eigentlich nur einmal im Monat ändern (Reklamebilder usw.). Soll ich die jetzt jeden Tag mitsichern ?

[Perlsau]

Hier bietet sich ganz klar die Verwendung zweier Datenbanken an: Eine für die täglich anfallenden Daten, eine für die "megagroßen Blobfelder" oder was auch immer deine 10 Gig belegt.

Aus Interesse: Wie lange dauert bei dir so ein Backup einer 10 Gigabyte Firebird-Datenbank? Ich hab eben mal bei mir nachgemessen. Das Backup meiner derzeit größten FB-DB mit ca. 2,7 GB dauerte 95 Sekunden auf demselben Laufwerk.