DBLookupComboBox ohne Lookup-Tabelle

[Perlsau]

Zitat von Furtbichler:

Zitat von Perlsau:

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.

Zitat von Furtbichler:

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.

Zitat von Furtbichler:

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?