@ Bernhard: Ok, da hab ich etwas geschlampt, die eigentliche Antwort hat ja bereits generic geliefert. Man benötigt Grant Angaben für den View.
Der View ermöglicht die spaltenabhängige Filterung und löst das Problem.
Meine Aussage zu der Spaltenberechtigungen, die darüber hinaus direkt auf Tabellenebene möglich sind, ist lediglich eine Entgeegnung zu Deiner Aussage, dass
DB dafür (".. so hohe Granularität der Zugriffsrechte..") nicht gemacht sein sollen.
Zugriffs-
API, Lizenzbestimmungen und Herstellergarantie sind natürlich zu berücksichtigen, wenn man ein System gekauft hat. Ob das die Regel ist, wage ich zu bezweifeln. Es gibt sicher genügend Firmen, die selbst (eigenverantwortlich) Datenhaltung und Verarbeitung betreiben und volle Hoheit darüber haben. Auch Standardsoftwarehersteller haben anwendungsintern die Problemstellung, Zugriffssicherheit zu bewerkstelligen. Ein wasserdichtes Datenmodell ist auch da der beste Weg.
@Furtbichler: Die Wahrung der definierten Rechte ist genau eine der Hauptaufgaben eines
DB Servers. Er muss es garantieren (können, ob der Entwickler es nutzt ist eine andere Frage), dazu sind die Berechtigungsverfahren einer professionellen
DB ja da und zwar vollkommen unabhängig davon, wer wie darauf zugreift. Mir ist nicht klar, warum das Konzept, dass es tabellenseitig (oder View, oder Stored Procedure) gibt, auf Spaltenebene nicht geben sollte. Das Argument, die Zugriffsschicht muss dann erhöhten Aufwand treiben, ist die logische Konsequenz der Anforderung, aber kein Gegenargument. (Wasch mich, aber mach mich nicht nass?)
Standardfall: Wird programtisch ein Update auf eine Tabelle ausgeführt, für das keine Erlaubnis besteht, muss die Zugriffsschicht ja auch damit klar kommen, sprich der Programmierer entsprechende Maßnahmen ergreifen.