Ini-Datei in DB-Feld verlegen

[Perlsau]

Zitat von baumina:

Diese INI-Dateien müssen in die DB verlagert werden, damit ich von überall Zugriff drauf habe.

Ich würde hier gleich Nägel mit Köpfen machen und jeder DLL eine eigene Tabelle spendieren, die alle Einstellungen aufnimmt. Ähnlich verfahre ich in allen meinen Database-Applications: Einstellungen werden in Tabellen gespeichert, der Index ist die Benutzer-ID. Damit die Tabellen nicht zu umfangreich werden, verwende ich mehrere Einstellungstabellen:

• Tabelle Benutzer für Benutzername, Passworthash, Formularpositionen und -größen, Farbeinstellungen und Sonstiges;
• Tabelle BTab für Sortier- und Tabelleneinstellungen;
• und je nach Bedarf noch diese und jene Tabelle.

Die Benutzertabelle enthält einen PK mit automatisch erzeugten IDs. Die anderen Benutzer-Tabellen verwenden die jeweilige ID ebenfalls als PK. Auf diese Weise kann bei Muli-User-Anwendungen jeder Benutzer seine individuellen Einstellungen speichern.

Zitat von Bernhard Geyer:

Lustig ist hier das man dir Registry empfiehlt ob diese ja auch schon wieder "böse" ist. Heutzutage würde man xml-"ini"-Dateien verwenden.

Oder gleich ein TClientDataSet verwenden, falls man keine Datenbank-Anwendung baut.

[mkinzler]

Eine Tabelle pro Dll ist nicht notwendig. Flexibler ist es diese als Schlüssel oder noch besser in eine eigene Tabelle zu verwalten.

[Sir Rufo]

Es ist doch völlig Wurscht, ob jede DLL eine eigene Tabelle hat, oder ob es eine Gesamt-Tabelle gibt. Der DLL/Anwendung muss das egal sein. Die Implementierung der Zugriffsklasse/Interface muss das wissen und sonst keiner.

Ab dann habe ich alle Freiheiten der Welt und kann auch zum Testen einfach mal eine Dummy-Implementierung drunter hauen, oder eben eine Tabelle ansprechen, oder eben eine für jede DLL, oder für DLL x eine Datei, DLL y die Registry, für die Anwendung ein Zugriff auf alles zusammen ...

[mkinzler]

Die Erweiterung, um eine Dll ist dann aber einfacher. Zudem entspricht das eher (meinem) Verständnis von Normalisierung.