embedded DB als Projektdatei nutzen?

[moelski]

Moin !

Ich hät da mal ne Frage genereller Natur ...

Angenommen wir haben eine MDI Anwendung wo die MDI Childs alle z.B. ein RichEdit haben. Wäre es dann denkbar das man die Inhalte der RichEdits in einer Datenbank ablegt (und zusätzlich die ganzen Randinformationen zu dem Projekt)?
Und die Datenbankdateien nutzt man dann quasi als Projektdateien für seine Anwendung. Beim Speichern des Projekts werden nun alle MDI Childs durchgeklappert und deren RichEdit Inhalt wird in der Datenbank in einer Tabelle abgelegt. Beim Laden einer Projektdatei würden aus der Datenbank eben alle Inhalte gelesen und in die MDI Fenster zurückgeschrieben.
Und pro Projekt legt man eben eine neue Datenbank(datei) an.

Wäre sowas erstmal generell machbar (evtl. über BLOB Felder !?)? Und was würde generell gegen ein solches Vorgehen sprechen?
Ich habe gesehen das man z.B. bei der Absolute Database die BLOB Felder komprimieren kann. Ein wirkliches Größenproblem dürfte sich dann nicht ergeben.

[mkinzler]

Zitat:

Wäre sowas erstmal generell machbar (evtl. über BLOB Felder !?)? Und was würde generell gegen ein solches Vorgehen sprechen?

Nichts.
Man könnte es aber auch in einer Datenbnak machen

[moelski]

Moin !

Zitat:

Nichts.

Bedeutet, das Vorgehen ein Blob für solche Daten zu "missbrauchen" wäre vollkommen i.O.?

Zitat:

Man könnte es aber auch in einer Datenbnak machen

Wie meinst du das?

[nahpets]

Hallo,

Zitat von moelski:

Moin !

Zitat:

Nichts.

Bedeutet, das Vorgehen ein Blob für solche Daten zu "missbrauchen" wäre vollkommen i.O.?

Ja, das ist in Ordnung, Blobfelder wurden extra dafür geschaffen.

Zitat von moelski:

Zitat:

Man könnte es aber auch in einer Datenbnak machen

Wie meinst du das?

Es muss keine embedded DB sein, dafür darf es durchaus auch eine Datenbank auf einem Datenbankserver sein, kommt halt auf den Art und Umfang der Daten an.

[moelski]

Moin !

Zitat:

Es muss keine embedded DB sein, dafür darf es durchaus auch eine Datenbank auf einem Datenbankserver sein, kommt halt auf den Art und Umfang der Daten an.

Ah ok. Ja das stimmt. es könnte auch ein Server sein.
Aber wie oben geschrieben würde ich gerne pro Projekt eine eigene Datenbankdatei anlegen. Und ich weiss nicht ob das mit einem Server so einfach machbar ist Wäre dass dann nicht jedesmal eine neue Datenbank?

Ich habe jetzt mal einen kleinen test gemacht.

Delphi-Quellcode:

procedure TfrmMain.btLoadImageClick(Sender: TObject);
var
  FileStream : TFileStream;
  BlobStream : TStream;
begin
 if (odBlob.Execute) then
   begin
     tVenues.Edit;
     try
       BlobStream := tVenues.CreateBlobStream(tVenues.FieldByName('Venue_Map'),bmWrite);
       FileStream := TFileStream.Create(odBlob.FileName,fmOpenRead or fmShareDenyNone);

       BlobStream.CopyFrom(FileStream,FileStream.Size);

       FileStream.Free;
       BlobStream.Free;
       tVenues.Post;
     except
       tVenues.Cancel;
       raise;
     end;
   end;
end;

Dieses Konstrukt fügt in eine bestehende Absolute DB ein Bild ein. Ich habe da mal ein 30MB BMP reingeschrieben. Funzt wunderbar, allerdings ist meine Anwendung für Sekunden komplett geblockt. auch beim Laden hängt die Anwendung.

Gibt es da Mechanismen um das ablegen und aufrufen von Daten im Hintergrund laufen zu lassen ohne das meine Anwendung hängt?

[nahpets]

Hallo,

das Hängen der Anwendung wirst Du nicht gänzlich verhindern können, es ist u. a. abhängig von der Datenmenge, die Du speicherst. 30 MB Bild als Blob, ist erstmal viel. Wenn Du auf diese Weise Adressen... speicherst, wird das in der Regel so schnell gehen, dass der Anwender davon (fast) nichts merkt.

Die Geschwindigkeit dürfte auch nicht unerheblich von der Art der Datenbank, der Leistungsfähigkeit des Datenbankservers, der Leistungsfähigkeit des Clients... abhängen.

Ob es sinnvoll ist, das Speichern von Daten in einen Thread auszulagern, mag ich nicht beurteilen.

Am Anfang sprachst Du von RichEdit, wenn es da hauptsächlich um Textverarbeitung geht, sollten die Antwortzeiten eigentlich nicht allzu hoch werden, es sei denn, die Texte enthalten viele oder große Bilder oder es sind eher Diplomarbeiten als normale Briefe.

Benötigst Du für jedes Projekt eine eigene Datenbankdatei oder reicht es, für jedes Projekt eine Tabelle in eine Datenbankdatei zu legen oder wäre es nicht sinnvoller, in einer Datenbank eine Tabelle anzulegen und die Tabelleninhalte über entsprechende Schlüssel, einem Projekt zuzuordnen.

Hier wäre es eventuell hilfreich, wenn Du uns etwas genauer mitteilen könntest, was Du insgesamt vorhast.

Z. B.: Eine Anwendung mit einer embeddeb DB, die die DB pro Client hat, wobei auch jedes Projekt eine eigene Datenbankdatei hat, damit die Datenbankdateien zwischen den einzelnen Clients ggfls. auch per USB-Stick ausgetausch werden können.
Oder soll es eine Anwendung werden, die auf vielen Clients läuft, wobei jeder Client eigentlich alle Projekte bearbeiten können soll (weil die Datenbankdateien z. B. auf einem für alle zugreifbaren Laufwerk liegen)...
Oder soll es eine Anwendung sein, die auch vom USB-Stick lauffähig ist und so incl. Datenbankdateien an jedem Rechner benutzt werden kann?
Soll die Software für den gelegentlichen Gebrauch ausreichen oder die tägliche Arbeit effektiv unterstützen (quasi ein Winword mit direkter Dokumentenablage in einer Datenbank)?

[moelski]

Moin !

Zitat:

... oder die tägliche Arbeit effektiv unterstützen (quasi ein Winword mit direkter Dokumentenablage in einer Datenbank)?

Das triffts eigentlich ganz gut.

Unsere Testanwendung ist bis jetzt etwas komplexer, deswegen hatte ich mich oben nur auch RichView beschränkt. In Wirklichkeit gibt es dort TRichView, TMemo und TChart. Für diese Komponenten gibt es quasi jeweils ein MDI Fenster wovon der User soviele anlegen kann wie er mag.

All diese Fenster halten ja eine gewisse Menge an Daten vor und das muss eben irgendwann mal irgendwohin gespeichert werden.

Dabei ist es aber eher so das man nicht mit mehreren Usern auf einer Datei arbeiten kann. Das macht auch eigentlich bei uns keinen Sinn. Vielmehr hat der User verschiedene Projekte (=Dateien) in denen er seine Daten organisiert. Eine Datenbank macht da keinen Sinn.
Der Vergleich mit Word ist da schon passend. Es ist quasi so als wenn man einen Lebenslauf und ein Testament in Word schreibt. Das passt auch nicht wirklich in eine Datei auch wenn es formell gehen würde

Zitat:

das Hängen der Anwendung wirst Du nicht gänzlich verhindern können,

Ohje ... Das ist nicht gut.
Ich hatte die Hoffnung das sich die DB Kompoenente im Hintergrund selber um das Lesen / Schreiben kümmert ohne damit die Hauptanwendung zu belasten. Scheinbar ist dem wohl nicht so

[nahpets]

Hallo,

naschön, das Bild wird deutlicher.

Da könntest Du es mal mit Threads zum Speichern probieren (da hab' ich aber keine Ahnung von).
Aber bedenke bitte vorher:

Anwender speichert, während der Speichervorgang im Hintergrund läuft (kann ja was dauern), speichert der Anwender schon wieder, er ist halt ungeduldig oder hatte noch eine kleine Korrektur...

Damit muss Du dann umgehen können.

Kannst Du an den einzelnen MDI-Fenstern erkennen, ob es eine Änderung gegeben hat? Wenn ja, nur die geänderten speichern.

Wie oft muss der Anwender speichern, alle Nase lang oder wenn er die Arbeit erledigt hat...

Mach' Deinen "Zeittest" doch bitte auch mal mit TMemo und TRichEdit mit "handelsüblichen" Datenmengen, bei den TCharts mag so eine Grafik schon einiges an Platz/Zeit benötigen. In welchem Umfang wird denn was benötigt. Sind große Grafiken eher der Normalfall oder eher die Ausnahme?

Was ist mit Datenbankkomponenten?

TMemo -> TDBMemo
TRichEdit -> TDBRichEdit
TChart -> TDBChart

Gespeichert wird letztendlich beim Post, unabhängig davon, ob nun "normale" oder Datenbankkomponenten genutzt werden. Die Datenbankkomponenten ersparen Dir den Transfer der Daten von der nicht datenbanksensitiven Komponente in die Datenbankkomponente (tVenues.FieldByName('irgendwas').As...).

[moelski]

Moin !

Zitat:

Da könntest Du es mal mit Threads zum Speichern probieren

Ich hatte gehofft das mir die DB genau das abnimmt ...
Denn Threadbasiert speichere ich derzeit schon... Allerdings würde das mit einer DB einfacher gehen. Drum überhaupt der Gedanke an ein DB Konstrukt ...

Zitat:

Anwender speichert, während der Speichervorgang im Hintergrund läuft (kann ja was dauern), speichert der Anwender schon wieder, er ist halt ungeduldig oder hatte noch eine kleine Korrektur...

Sowas kriegt man raus. Das stellt kein Problem dar.

Mach' Deinen "Zeittest" doch bitte auch mal mit TMemo und TRichEdit mit "handelsüblichen" Datenmengen Es gibt keine Handelüblichen Mengen. Jeder User entscheidet was ihm wichtig ist an Daten. Und ich muss eben mal den Worst Case betrachten (wobei 30MB noch nicht worst Case sind ...)

Ich habe mal ne Mail an den Hersteller von Absolute Database geschickt. Mal sehen ob dir mir da einen Tip geben können.

[ConstantGardener]

Hallo moelki,

ich hatte ähnliche Ideen zu einer unserer Anwendungen. Ich speichere jedoch nur Verweise auf die Dateien in der DB. Die Dateien liegen dabei in einem speziellen Unterordner des Datenbankordners für Metadaten. Die komplette DB mit den Metadaten packe ich dann per zip in eine einzige Datei (mit anderer Dateiendung und wenn Du willst mit Passwort). Der Anwender merkt dadurch nicht, daß er mit einer DB arbeitet. Für ihn sind seine Projekte wie Word-Dateien zu handeln. Zusätzlicher Bonus : Das Laden der Metadaten (Texte,Grafiken usw.) kannst Du in Threads auslagern. Bei nativen Formaten kannst Du die Arbeit an andere Programme abgeben (z.B. Word) da die Dateien im Orginal erhalten bleiben. Hat sich bei uns ganz gut bewährt. Als EmbeddedDB nutzen wir NexusDB. Absolute Database sollte sich aber genauso nutzen lassen.

cg