DBLookupComboBox ohne Lookup-Tabelle

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.

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.

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

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?

Zitat von Perlsau:

Naja, mein lieber Furtbichler, ein so großer Schwachmat bin ich dann doch wieder nicht.

Hast Du den Grinsemann am Ende meines 'Einwandes' gesehen? Ja. Korrekt interpretiert? Offensichtlich nicht.

Zitat:

Das führt uns jetzt aber doch wenig zu weit weg vom ursprünglichen Thema, oder nicht?

Ganz und gar nicht. Das ist das große Problem von Lookuptabellen bzw. der Problematik, Geschäftsregeln an mehr als einer Stelle zu hinterlegen. Wie löst Du denn dieses Problem? Woher weiß dein Programm, das Süss=1 ist? Steht das irgendwo? Ja, oder? Im Code *und* in der Datenbank.

**jobo**

Zitat von Furtbichler:

..
Leider gibt es ein kleines Problem dabei, ...

Ich versteh das Problem mit der doppelten Definition nicht so richtig.
Entweder ich arbeite mit irgendwelchen Nutzdaten, dann sind ID und Text (egal welche Sprache) erstmal wurscht.
Konkret, erfindet mein Kunde eine neue Produktgruppe und verwendet diese bei der Anlage neuer Artikel, kann das der DB, der Anwendung und mir egal sein.
Oder ich arbeite mit- nennen wir es Anwendungsdaten- deren Werte durch die Businesslogik verwendet werden. Hier hat der Benutzer nichts zu editieren, weil er bestenfalls nichts Neues schafft, eher aber bestehende Zusammenhänge zerstört. Als Entwickler muss man dafür sorgen, dass diese Daten (auch beim Erstellen oder migrieren einer Datenbank) konstant bleiben.
Konkret, hat mein Kunde die Gruppe Grillfleisch angelegt, muss er eine weitere Zuordnung dieser neuen Produktgruppe treffen, die entsprechend im System registrierte Regelwerke und Stammdaten für Lebensmittel/(frisch)Fleisch definiert.
In diesem Bereich der Anwendungsdaten ID oder Texte zu editieren ist selbst dann sinnlos, wenn alle Zusammenhänge bekannt sind / berücksichtigt werden, da für die neue Daten keine korrespondierenden Regeln im System vorliegen.

Was sehr praktisch ist bei dem ganzen Thema:
Lookup Daten per View bereitstellen. Damit habe ich einen extra Freiheitsgrad, den ich für unterschiedlichste Zwecke einsetzen kann.

Zitat von jobo:

Ich versteh das Problem mit der doppelten Definition nicht so richtig.

Es ist ein Designproblem. Die Tatsache, das z.B. Grün=1 ist, ist -wie erwähnt- an zwei Stellen hinterlegt. Im Code hast Du z.B.
In der Datenbank

ID	Text
1	Grün

Und im Code

markieren

Delphi-Quellcode:

			Const

  Gruen=1;

...

Case Farbe of

  Gruen : MalEsGelbAn();

  Rot : StampfEsEin();

...

Problem ist, wenn Du entweder die CONST-Deklaration oder aber den eintrag in der Lookuptabelle änderst (oder der Kunde).

ID	Text
1	Rot
2	Grün

Denn dann wählt der Anwender 'Grün' aus und die Anwendung macht jetzt etwas anderes.

Zitat:

Konkret, erfindet mein Kunde eine neue Produktgruppe und verwendet diese bei der Anlage neuer Artikel, kann das der DB, der Anwendung und mir egal sein.

Absolut korrekt. Derartige anonyme Daten sind von dieser Problematik nicht betroffen. Das Problem besteht bei Ausprägungen (also Daten), deren Bedeutung im Code eine Rolle spielt.

Zitat:

Oder ich arbeite mit- nennen wir es Anwendungsdaten- ... eher aber bestehende Zusammenhänge zerstört. Als Entwickler muss man dafür sorgen, dass diese Daten (auch beim Erstellen oder migrieren einer Datenbank) konstant bleiben...

Genau. Und darauf wollte ich hinaus.

Zitat:

In diesem Bereich der Anwendungsdaten ID oder Texte zu editieren ist selbst dann sinnlos

ID = ja. Text = nein. Text muss editierbar (oder besser: veränderbar) bleiben.

Zitat:

Was sehr praktisch ist bei dem ganzen Thema: Lookup Daten per View bereitstellen.

Das ist eine gute Idee, denn ich kann z.B. die Mehrsprachigkeit hinter der View verbergen.