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