Doofe Situation mit gemeinsam genutzten Dateiressourcen

[Sir Rufo]

Zitat von Iwo Asnet:

Overkill für eine Konfiguration, oder?

Die "Konfiguration" ist ja nun auch nicht gerade "Ponyhof"

Zitat von QuickAndDirty:

-Einstellungen( internes Rechte Management, Farben Beschriftung, Parameter für die Geschäftslogik, Parameter für angeschloßene Hardware )
-Datei die den internen Aufbau der Datenbank kennt initialisierungs Datensätze für verschiedene Tabellen enthält
-Objectcode Dateien für einen im Fatclient integerierten Interpreter
-Objectcode Dateien für Berichte

[jobo]

Für unsere Fatclients kommt sämtliche Konfiguration aus der DB.
Das beinhaltet Labels(inkl. I18), Rechte (natürlich Grants, aber auch alles was damit nicht geht), Konfig- und Steuerdaten, XML in CLOBs, ganze Dateien (z.B. Excel Templates) in BLOBs.
Die Fat Clients (Delphi und c#) haben lediglich einige Command Line Schalter.

Das Beste daran ist die zentrale Pflege dieser ganzen Daten.
Also m.E. spricht alles für eine DB gestützte Konfiguration. Also z.B. mORMot. Wenn die bestehende Lösung in Richtung Filekonfiguration gut gekapselt ist, ist ein manueller "Tausch" gegen DB vlt. gar nicht so aufwendig.

[QuickAndDirty]

"nicht Ponyhof" = scheiße ????

Zitat von jobo:

Für unsere Fatclients kommt sämtliche Konfiguration aus der DB.
Das beinhaltet Labels(inkl. I18), Rechte (natürlich Grants, aber auch alles was damit nicht geht), Konfig- und Steuerdaten, XML in CLOBs, ganze Dateien (z.B. Excel Templates) in BLOBs.
Die Fat Clients (Delphi und c#) haben lediglich einige Command Line Schalter.

Das Beste daran ist die zentrale Pflege dieser ganzen Daten.
Also m.E. spricht alles für eine DB gestützte Konfiguration. Also z.B. mORMot. Wenn die bestehende Lösung in Richtung Filekonfiguration gut gekapselt ist, ist ein manueller "Tausch" gegen DB vlt. gar nicht so aufwendig.

ja vielleicht könnte man die Dateien wirklich einfach in eine
Datenbank mit blobs legen. Nur aus Paradoxzeiten herrscht bei mir irgendwie eine gewisse unsicherheit was blobs angeht vor.
Habe mir überlegt das es vielleicht sinnvoll ist das ganze über einen Syncserver zu machen
ich hätte dann in der Datenbank eine Tabelle mit

ID | DATEIPFAD | ZEITSTEMPELL | BLOB

Der Syncserver würde jede 5 min mal alle Dateien auf aktuallität prüfen und gegebenenfalls neu importieren, vielleicht sogar historisiert. Oder eben wenn der Zeitstempel in der DB Aktueller ist
als die Datei die Datei mit dem Blob überschreiben.

So hätte ich immer noch ein einfaches transportieren von einzelnen Kundenspezifischen Reports und Makros. Und immer sowas wie eine Kopie falls die Blobs mal kaputt sind.

Nachteil wäre natürlich das man immer ganze Blobs lesen und schreiben müsste.

[Sir Rufo]

Das mit dem SyncServer ist dann aber auch mehr durch die Brust ins Auge.

Und sauber ist das auch nicht, da es zu viele "nur wenn" gibt.

Aus diesem Grund packt man das besser in eine DB und jeder Client kann die Daten lesen und schreiben, wie er gerade lustig ist.
Beim Zugriff auf die Daten prüft man nur schnell, ob der Zeitstempel des Objekts noch aktuell ist und aktualisiert das Objekt im Bedarfsfall.

[QuickAndDirty]

Zitat von Sir Rufo:

Beim Zugriff auf die Daten prüft man nur schnell, ob der Zeitstempel des Objekts noch aktuell ist und aktualisiert das Objekt im Bedarfsfall.

Aktuell gemessen an der Datei oder aktuell in bezug auf einen Cache?

[Sir Rufo]

Zitat von QuickAndDirty:

Zitat von Sir Rufo:

Beim Zugriff auf die Daten prüft man nur schnell, ob der Zeitstempel des Objekts noch aktuell ist und aktualisiert das Objekt im Bedarfsfall.

Aktuell gemessen an der Datei oder aktuell in bezug auf einen Cache?

Ich sprach ja jetzt davon, alle Daten in einer DB zu halten.

Wenn du mORMot einsetzt, dann gibt es bei jedem Objekt (TSQLRecord) eine Eigenschaft "InternalState".
Der Server hat auch einen InternalState, der bei jeder DB-Änderung hochgesetzt wird.

Somit muss man nur diese beiden Werte vergleichen und wenn sich die unterscheiden, dann einmal einen Refresh, ansonsten ist alles schick.

Macht allerdings nur dann Sinn, wenn man eine eigene Konfigurations-DB einsetzt - in der Produktions-DB wird es ja wohl laufend Änderungen geben.

[jobo]

Mach doch einfach mit Deiner CLient Architektur / Connectivity einen Schreiblesetest für CLOB/BLOB.
Wenn das klappt ist doch alles ok. BLOB ist ja kein Voodoo mehr, Paradox ist lang her.
Wenn Du es auf die Spitze treiben willst, kannst Du natürlich deine ganzen Konfig files zippen und in einen Selfextractor packen. Die Clients behalten ihre File basierte KOnfiguration, speichern das aber lokal.
Ein "ganzes BLOB" ist aber auch nicht so ein Thema, manche DB-Clients komprimieren hier bereits bei der Übertragung. Und so aus dem Bauch würde ich sagen, dass der "normale" Datenverkehr bei TDataset Operationen Browse,Edit,Insert,Update mehr Overhead erzeugt, als mal ein BLOB runterzuladen.

Stehen in den Konfigdaten auch individuelle Benutzereinstellungen? Dann müsste man sicher etwas filigraner vorgehen.

[QuickAndDirty]

Zitat von jobo:

Stehen in den Konfigdaten auch individuelle Benutzereinstellungen? Dann müsste man sicher etwas filigraner vorgehen.

Ja !
Es gibt eben eine baum artige Konfigurationsdatein mit userspezifischen Zweigen...
Ich persönlich würde mir speziell diese Datei durch schreibend wünschen...sprich das jede änderung
sofort wirksam wird...habe schon mal angedacht eine "Teile Tabelle" dafür zu nehmen...
Aber ein erster schritt wäre sicher alles in blobs zu packen.

[Iwo Asnet]

Zitat von Sir Rufo:

Die "Konfiguration" ist ja nun auch nicht gerade "Ponyhof"

Gnfrrzl.. von mir aus. Aber eigentlich auch nur ne fette INI-Datei.