Doofe Situation mit gemeinsam genutzten Dateiressourcen

[QuickAndDirty]

Ich will keine Freigaben mehr, weil mir die Windows Rechte auf den Sack gehen, und die virenscanner &c. !

Ich habe hier die Situation das verschiedene Programme auf gemeinsam genuzte Dateiressourcen zugreifen.
Es handelt sich dabei um Fatclients. Und ein Großteil der Probleme rührt wohl daher das der Client zu Fett ist.

Dateien die gemeinsam im Zugriff sind sind in erster linie:
-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

Also es sollen schon fatclients bleiben(zumindest wäre es erstmal zuviel arbeit das zuändern)

Folgende Gedanken habe nich mir dazu gemacht.
1.
-Verlagern der Globalen Einstellungen in die Datenbank. Wäre etwas Arbeit, aber möglich
-Verlagern der objectcode Dateien in Blobs in die Datenbank. Wäre möglich, aber ich fühle mich bei blobs in datenbanken immer ungut.

2.
-einfach einen Passwort gesicherten FTPserver vom Setup auf dem Server mit installieren und die Dateien per FTP laden und schreiben. hört sich schon irgendwie lahm und unsicher an.

3.
-Einen eigenen Bereitstellungsserver(?) für diese Daten schreiben und auf dem Server installieren.
hätte den Vorteil das wirklich alles in eigener Kontrolle ist und man die Schreib und lese Methoden aus dem FatClient-Source rauskopieren könnte.


Was gäbs noch? Was würdet ihr als Kurzfristige Lösung nehmen?

[Iwo Asnet]

BLOBs sind kein Problem. Was soll da schiefgehen? Ist schnell umgesetzt. Wir haben PDF-Dateien komplexer XML-Dokumente als BLOB in einer MSSQL-Datenbank.

[Sir Rufo]

ich werfe mal mORMot in die Runde ...

[Iwo Asnet]

Overkill für eine Konfiguration, oder?

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

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

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

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