der Anwender bedient schliesslich ein UI und keine DB
Dann wird halt im Code der UI gebastelt, falls die Enum Werte noch übersetzt werden müssen.*
Ich kann die Performanceproblematik und das Komplexitätsproblem schon verstehen. Aber ob man sich mit Enums den A.. retten kann, ob also viele Nachschlagetabellen diese Problematik verursachen, wage ich zu bezweifeln. Da z.B. die Frage, wie denn die Enums auf der DB implementiert sind. (Sinnlos, wenn sie nicht implementiert sind) Wenn es gut gemacht ist, wahrscheinlich mit einer versteckten, normalisierten Tabelle und FK.
Erfahrungsgemäß ist z.B. in komplexen, großen DB das Löschen ein Problem, außer es wurde dafür eifrig eine Optimierung gepflegt.
Meine andere Erfahrung ist, dass konkurrierende Zugriffe (viele Benutzer) in MSSQL grundsätzlich ein Problem sind, Lock Escalation, ... Ist zum Glück schon was her, ist bestimmt besser geworden.
da hat meine jetzige Firma mal 180TB von Oracle nach PG migriert .
Größe ist nicht unbedingt gleichbedeutend mit Komplexität, wahrscheinlich bei Banken auch eher weniger.
@Walter
Wenn Du Dir sicher bist, dass separate Hilfstabellen oder der alte, String basierte Check Constraint zu viel Ressourcen kosten (was ich grundsätzlich nicht vermuten würde),
und eh (immer) die UI dazwischen hängt (App Server, REST API oder so)
und es vielleicht gar kein heterogenes System ist
und auch keine Spezis zu Fuß in der DB rumwurschteln,
dann trag nur Rohwerte ein und prüfe die zyklisch auf Gültigkeit in einer Phase, wo wenig Last auf der DB ist.
Es wäre am Ende eine Frage von Mutwillen, Doofheit oder Programmfehlern, wenn falsche Werte reinkommen. (Ja, ich weiß, dass es das trotzdem gibt)
Komplexe Inserts oder Updates zu verbieten (Grant) und durch smarte SP zu ersetzen, kann da auch Vorteile bringen.
* Das ist natürlich auch eine zulässige Strategie, um Last von der DB zu nehmen. Zumindest, wenn es gut umgesetzt ist. MS macht es ja sogar mit seinem .NET offline Verfahren ziemlich krass, wenn FAT Clients nur zum Lesen und Schreiben verbinden und keine durchgehenden Sessions haben. Ich weiß ehrlich gesagt gar nicht, ob das im Zeitalter von tonnenweise RAM auf dem DB Server noch so praktiziert / propagiert wird von denen.