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
Und im Code
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).
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.