Das kann auf verschiedenen Wegen sichergestellt werden, z.B. mittels "with check" im Create View statement stellt man sicher, dass Update oder Insert nicht die Where Kriterien verletzt, naheliegend wäre auch eine Stored Procedure für insert/update, die das sicherstellt.
Und wie kompliziert wird das? Vor allem Aufwändig wenn man das für alle Unterstützten
DBMS realisieren müsste.
Mit den oben beschriebenen Möglichkeiten lässt sich das bewerkstelligen. Was Du schilderst geht aber teilweise in den Bereich Business Logik, work flow. Wenn hier absehbar ist (oder gar systematisch vorgegeben), dass häufige Veränderungen auftreten, ist das Datenmodell ungeeignet, das abzubilden.
Wirklich? Glaube ich nicht das das so eine auf
DBMS-Mitteln basierende Rechtevergabe noch eine wartbare SW darstellt.
Davon ist aber im vorliegenden Fall nicht die Rede gewesen.
Wir wissen nicht wie komplex die Anwendung ist die realisert ist/werden soll.
Prima, solange es
DB Bordmittel gibt, Missbrauch oder Programmierfehler zu verhindern, kann man die doch ganz entspannt einsetzen.
2-3
DB-Gruppen ist was anderes als das was ein ERP oder ein PLM als Rechtesystem benötigt.
Um es mal klar zu sagen. Die Frage des TE roch nicht gerade danach, dass eine Mittelschicht eingesetzt wird. Eine solche (generell) vorzuschlagen, scheint mir halt so pauschal unpassend bzw. nicht unbedingt hilfreich für den TE. Oder eben in diesem Fall hier Kanonen auf Spatzen. Und wie ich schrieb, dass RDBMS für sowas nicht gedacht, gemacht, zu gebrauchen sind, ist halt eine sehr fragwürdige Aussage.
Stimmt. Wir wissen nicht wie komplex das Gesamtsystem ist. Wenn es nur um eine solche Anforderung geht ist eine View z.B. ganz gut. Will man diese Methode für eine komplexere Anwendung als Pattern einsetzen ist man m. E. auf dem falschen weg.
Können wir aber gern in einem anderen Thread diskutieren.
Wäre eine möglichkeit.