Zudem vereinfacht es für mich die Implementierung, wenn ich nur mit einer Liste von Einzelwerten arbeiten kann.
Mit einer RANGES-Tabelle arbeitet man normalerweise per IN-Operator, und dann ist es egal, wie die enthaltenen Werte definiert sind.
Mh - da kann ich Dich nur zu Deinen Anwendern beglückwünschen. Ich habe leider bereits andere Erfahrungen gemacht... 😁
Anwender-Bashing ist immer wohlfeil, aber entweder jemand kann den Job, oder er kann ihn nicht. Klar kenne ich auch DAUs, aber wer überhaupt da hinten reingeht, der sollte wissen, was er tut, oder gar nicht erst die Berechtigung für die Transaktion haben, wenn er nicht damit umgehen kann.
Durch die Einschränkung kann sich das Programm darauf verlassen, dass nur definierte Werte in der Range vorhanden sind. Die Range wird ja nicht zwingend einfach an die Datenbankselektion "abgegeben", sondern auch mal für andere Zwecke ausgewertet.
Da würde ich einfach einen SELECT mit den Werten aus der RANGES-Tabelle machen und mit den Einzelwerten weiterarbeiten, die mir die Datenbank daraufhin liefert. Solch SELECT ist kürzer und einfacher als der Trick aus dem Tricktresor (auch wenn ich ihn hübsch finde), und dann hat man gleich noch die erweiterte Funktionalität, dass man auch die inhaltlich konsistente Möglichkeit von Intervallen hat (egal ob man sie braucht oder nicht).
Dass man das wirklich einschränken muss, sehe ich allenfalls dann, wenn man einen SELECT-OPTIONS für etwas missbraucht, was mit Selektionskriterien auf das hinter dem FOR stehende Feld gar nichts zu tun hat. Beispielsweise als Eingabefeld für einzupflegende Daten.