Ini-Datei in DB verlegt

[Edelfix]

Hallo,

wir habe vor ein paar Jahren die Ini-Datei in die Datenbank verlegt.

Im Quelltext wird an vielen Stellen auf die Ini-Datei zugegriffen. Deswegen haben wir eine TDBIni Klassen angelegt die sich wie eine Ini-Datei verhält.

Innerhalb der Klasse wird aus der Datenbank gelesen.

Mit der Zeit wurden es immer mehr Werte die gelesen werden müssen.

Da jeder Wert einzeln gelesen wird ist die Performance nicht sooo toll

Zum Beispiel:

Delphi-Quellcode:

myVar := ReadString('Section',1,'Name',DefaultValue);

Jetzt überlege ich eine "Schnell laden" Funktion zu erstellen die fix über 2000 Werte aus der DB liest.

Eventuell kennt jemand ein Beispiel wo der Umstieg von Ini-Datei auf DB dokumentiert / beschrieben wurde. Dann muss ich das Rad nicht neu erfinden.

[Sinspin]

Hallo,

wie oft ändern sich die Werte denn?
Ich würde die Tabelle, oder einzelne Sectionen einfachen in eine MemTable spiegeln und dann nur lokal auslesen.
Schreiben schreibt dann durch.
Zum prüfen auf Änderungen schreibt jeder editierer an den geänderten Wert den Zeitpunkt der Änderung dran.
Beim Auslesen prüft die Leseroutine erstmal ob sich in der Tabelle ein Wert befindet der neuer als der neuste vom letzten Lesen ist und ließt erst alles neu.
Das macht nur Probleme wenn zu oft geschrieben wird.

[joachimd]

Nicht MemTable, MemIni verwenden, bei Programmstart erzeugen und aus der DB befüllen. Bei Änderungen direkt zurückschreiben.
Beim Ändern der Werte in der DB, per Trigger eine Notification auslösen und darauf in der Anwendung reagieren (Wert neu laden).

[KodeZwerg]

Ich habe mir angewöhnt (vielleicht war es ein Fehler...) das meine Konfiguration im Programm ein Record oder eine Klasse ist und speichere/lade demzufolge nur einmal.

[Edelfix]

Es ist eine Server Basierende Anwendung. Es arbeiten teilweise bis zu 60 User gleichzeitig mit einer DB.
Wenn einer etwas ändert dann wird das direkt in die Datenbank gespeichert. Während der Änderung wird das Ändern für andere gesperrt.
Die Änderung erhalten alle anderen (und der die Änderung vornimmt), wenn sie ihre Anwendung neu starten.

Einer der Gründe warum die Änderung nur durch Neustart ankommt ist die lange Lade / Start Zeit der Anwendung.

Wenn ich das verkürzen könnte dann könnten die Änderungen direkt geladen werden.

Die Idee mit dem Änderungsstempel ist interessant.

[Sinspin]

Zitat:

Zitat von joachimd (Beitrag 1508726)

Nicht MemTable, MemIni verwenden, bei Programmstart erzeugen und aus der DB befüllen. Bei Änderungen direkt zurückschreiben.
Beim Ändern der Werte in der DB, per Trigger eine Notification auslösen und darauf in der Anwendung reagieren (Wert neu laden).

MemIni ist umständlich, die ermöglicht kein 1:1 kopieren ohne jedes Feld einzeln anzufassen. Auch ist es nicht möglich eventuell zusätzliche Felder mit zu kopieren.
Wenn man einmal eine Tabelle hat tut man sich doch nicht freiwillig etwas so unflexibles an.
Zudem müsste man dann auch noch den Zugriff auf die Daten neu schreiben.
Ich denke bei MemTable an TKbmMemTable, darauf ist bei uns alles optimiert. Ich bin mir aber sicher andere MemTables können alles nötige auch.

Und ADS Trigger lasse ich lieber bleiben. Auf Speicherlöscher und sich sporadisch beim beenden aufhängende Programme kann ich verzichten (ADS V11.10).

[Rollo62]

Du könntest auch versuchen mit JSON statt INI zu arbeiten um flexibler zu sein, oder
so eine ähnliche Struktur in der DB anzulegen.

[haentschman]

Moin...8-)

Zitat:

wird ist die Performance nicht sooo toll

Zitat:

ist die lange Lade / Start Zeit der Anwendung

...vieleicht sollte man das mal definieren? (in Millisekunden bis Stunden) + die Erwartung (in Millisekunden bis Stunden) :zwinker:

[Edelfix]

Das Laden dauert je nach Datenbank Größe etwa 20 Sek.

Die Datenbank Tebellen Struktur sieht so aus:

ID | Section | Nummer | Name | Typ | Bool | Integer | String
----------------------------------------------------------------------
1 | Systemeinstellung | 1 | LKZ | 2 | | | DE
2 | Systemeinstellung | 1 | BetreffFett | 0 | true | |


Das befüllen der TMemIni müsste ich neu programmieren.