@ 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.
Lesen schon, aber wie ist es mit dem schreiben wenn er nur entsprechende Datensätze auch schreiben darf?
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.
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.
Die Aussage bezieht sich auch die obige Notwendigkeit Rechte entsprechend auf Zellenwerte zu vergeben. Da kommt man mit Grants nicht weit.
Und der Alttag (ERP und PLM's zeigens) ist ja das man die so auch benötigt.
Sachbearbeiter A darf nur Stammdaten bearbeiten die im Bereich Elektrik liegen
Sachbearbeiter B darf keine Stücklisten bearbeiten welche freigegeben sind, dies müssen dann von Sachbearbeiter C als neue Version wieder in den Zustand "in Arbeit" gesetzt werden.
Wie würden hier GRANDs auf Datenbankebene aussehen?
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. Davon ist aber im vorliegenden Fall nicht die Rede gewesen.
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.
Ich nicht. Bei SAP-Installationen wirst du oft nur direkten Tabellenzugriff (als mit Schreiben) bekommen wenn du das über die Geschäftsführung als Weisung an die IT bekommst. Die IT wird hier nicht die Gefahr eingehen das wegen eines Programmierfehlers das Werk stundenlang steht.
Äh, ich hab ja geschrieben, dass die Lizenzbestimmungen usw. einzuhalten sind. Wer an oder besser in SAP rumschraubt ist sowieso selber schuld. Da wär mir persönlich auch das Einverständnis der GF egal, die müssten mich schon "zwingen". Allein die Frage, was mir beim nächsten SAP Update alles um die Ohren fliegt, halte ich schon für nicht zu beantworten.
Es gibt sicher genügend Firmen, die selbst (eigenverantwortlich) Datenhaltung und Verarbeitung betreiben und volle Hoheit darüber haben.
Als Eigen-SW und keine Kauf-SW?
Genau, davon rede ich z.B.
Auch Standardsoftwarehersteller haben anwendungsintern die Problemstellung, Zugriffssicherheit zu bewerkstelligen. Ein wasserdichtes Datenmodell ist auch da der beste Weg.
Haben wir. Wir haben 2-3 Usergruppen welche relativ einfache Rechtemodelle haben. Alles andere wird in der Anwendung erledigt.
[/QUOTE]
Prima, solange es
DB Bordmittel gibt, Missbrauch oder Programmierfehler zu verhindern, kann man die doch ganz entspannt einsetzen.
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.
Ich glaub, das geht aber hier schon deutlich Richtung
OT. Können wir aber gern in einem anderen Thread diskutieren.