In den meisten
DB-Anwendungen habe ich sogar die Benutzerverwaltung nebst Benutzereinstellungen in der Datenbank, denn wozu eine Ini-Datei oder Registry-Einträge, wenn ich sowieso eine Datenbank einsetze.
Na ja. Die Adresse des
DB-Servers in der
DB zu speichern ist vielleicht nicht ganz so zielführend.
Naja, mein lieber Furtbichler, ein so großer Schwachmat bin ich dann doch wieder nicht. Aber hier benötige ich auch weder Registryeintrag noch Inidatei, weil ich das gewöhnlich über Startparameter löse. Dort steht dann z.B. nur "0" drin, was bedeutet, daß es sich um eine Embedded Firebird
DB handelt, die im Anwendungsordner liegt, oder auch "0 E:\Datenbanken", wobei die
DB im bezeichneten Ordner liegt, oder auch "1 E:\Datenbanken", was lokaler
FB-Server mit
DB im angegebenen Verzeichnis bedeutet usw.
Aber sonst:
Leider gibt es ein kleines Problem dabei, das gelöst werden muss. Angenommen, wir haben eine Eigenschaft 'Geschmack' mit der entsprechenden Tabelle 'Süß', 'Sauer', 'Bitter', 'Salzig'. (Werte = 1,2,3,4)
Nun muß die Software bie einem süßen Gericht Schlagsahne anbieten. Also muss die Anwendung wissen, das 'Süß=1' ist. Das ist natürlich kein Riesenproblem, aber diese Tastsache ist an zwei Stellen hinterlegt (in der
DB und in der Anwendung). Ändert man z.B. die Reihenfolge in der
DB (bei einer Neuinstallation z.B.), funktioniert die ganze Anwendung nicht mehr.
Bei einer Neuinstallation sollten doch eigentlich alle vom Anwender eingegebene Daten aus der "alten"
DB übernommen werden. Ist die alte
DB nicht mehr verfügbar, spielt es keine Rolle, denn dann gibt es die Geschmacksrichtungen ja noch nicht. Oder diese Geschmacksrichtungen sind bereits fest vorgegeben (bzw. werden bei der Installation eingetragen), dann wird wohl auch die Reihenfolge eingehalten werden. Wenn ich z.B. Datenbank-Portierungen mache (entweder von zwei verschiedenen
DBMS oder innerhalb desselben
DBMS), werden immer zuerst die Sub-Tabellen übertragen, damit die Ids passen. Aber das hat doch mit meiner Vorgehensweise, benutzerdefinierte Einstellungen in der
DB abzulegen, nichts zu tun, es sei denn, du betrachtest alles, was der Anwender in die
DB einträgt, als benutzerdefinierte Einstellungen. Ich meinte damit lediglich das, was man gewöhnlich in den Optionen stehen hat nebst den sonstigen Values wie Fenstergrößen und -positionen, Spaltenbreiten usw.
Wie gesagt: Ein grundsätzliches Problem, das normalerweise nicht zum Tragen kommt (außer, ein Schwachmat editiert die Lookuptabelle), aber hier würde ich trotzdem noch Prüfungen einbauen und z.B. sicherstellen (per Trigger z.B.) das die Tabelle nicht änderbar ist. Alternativ kann eine solche Tabelle auch ein 'Tag' Element enthalten, das die eigentliche Semantik abbildet. D.h. nicht die ID der Lookuptabelle definiert die Eigenschaft, sondern das Tag-Element. Dieses Element kann nicht verändert werden, aber z.B. der Text, dann ist die Tabelle übersetzbar. Natürlich ist man wieder am Arm, wenn man 'Süß' mit 'Salt' übersetzt...
Das führt uns jetzt aber doch wenig zu weit weg vom ursprünglichen Thema, oder nicht?