Announcement

Collapse
No announcement yet.

Alternative zur Policy Oracle

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Alternative zur Policy Oracle

    ich gruße euch liebe Datenbankexperten,

    hat jemand von euch eine Idee, was ich als Alternative zur Policy in Oracle benutzen könnte.
    Das Problem ist, dass VPD-Konzept ist nur in Oracle Enterpreise Edition enthalten.
    Wie löse ich dieses Problem in Standard Edition oder in einer anderen Datenbank.
    Es muss bestimmt eine Funktion geben, die nicht nur auf insert, update, delete-Ereignis reagiert (ähnlich wie Trigger), sondern auch auf select-Anweisung. Wo ich den Zugriff auf Tupel vor der Ausgabe haben könnte und die Ausgabe beschränken.
    Oder ein Mittel, mit dem mann das select-String vor der Ausgabe erweitern kann.

    Aufgabenstellung blebt folgend:
    Angegeben wird:
    "select * from mitarbeiter"
    Umgewandelt werden muss in:
    "select * from mitarbeiter where abteilung = 2"
    und die Ausgabe entsprechend für die unterschiedlichen Abteilungen anders

    ich freue mich, auf eure Antworten

  • #2
    Natürlich geht das, es gibt verschiedene Möglichkeiten.

    Zum einen kannst du für jeden User (oder Gruppe) eine View erzeugen die du entsprechend einschränkst. Der User darf dann nur "seine" View selektieren, das kannst du über die normalen Rechte machen.

    Eine andere Möglichkeit ist es das Select Statement in einer Funktion zu kapseln. Der Ergebnis kannst du entweder als Objekt-Typ oder als REFCURSOR zurück geben.
    Einziger Nachteil dabei ist, dass du auch den Client umschreiben musst weil ein normales "SELECT" nicht mehr geht.

    [HIGHLIGHT=plsql]
    CREATE OR REPLACE FUNCTION mitarbeiter RETURN SYS_REFCURSOR IS
    res SYS_REFCURSOR;
    BEGIN
    OPEN res FOR SELECT * FROM mitarbeiter WHERE abteilung = 2;
    -- Es geht aus so: OPEN res FOR 'SELECT * FROM mitarbeiter WHERE abteilung = 2';
    RETURN res;
    END;
    [/HIGHLIGHT]


    Gruss

    Comment


    • #3
      ja, aber mit Views wird es zu aufwendig....Ich habe Hundert von Datenbanken, in jeder sind Tausende Tabellen, der Zugriff auf die Daten von denen nun userabhängig gesteuert werden soll. Die Anzahl der Nutzern ist auch unterschiedlich. So eine Vielzahl und Vielfalt von Views kann ich nicht verwalten.
      Der zweite Anzatz wäre auch zu Aufwändig, da dabei das Select-Statement in allen Anwendungen angepasst werden soll. Genau das wollte ich gerne vermeiden.
      Mit Enterprise Edition geht es wunderbar. Da gibt es mehrere Techniken dafür: man kann ein Select-Trigger implementieren(FGA) oder einfach das VPD nutzen.
      Das Problem ist, dass all diese Techniken nur in Enterprise Edition verfügbar sind.

      Was könnte man in Standard Edition in dieser Situation verwenden?
      Zuletzt editiert von study11; 19.02.2013, 16:33.

      Comment


      • #4
        Wir behelfen uns auch teilweise, weil die Kunden EE zu teuer finden.

        Die Abteilungen können sammt User/Login in einer separaten Tabelle landen. Einen View (pro UrsprungsTabelle)würde ich dann allerdings trotzdem noch spendieren. So ungefähr:

        [HIGHLIGHT=plsql]
        CREATE OR REPLACE View Vmitarbeiter as
        SELECT m.*
        FROM mitarbeiter m, abteilung a
        WHERE a.a_user = USER
        and a.abteilung = m.abteilung;
        [/HIGHLIGHT]
        In der Tabelle Abteilung müsste pro User eingetragen sein, welche Abteilungen er sehen darf.

        Wenn Du den View erweiterst mit "WITH CHECK OPTION", wird insert / update verhindert, sobald dadurch die Menge verändert wird, also die ursprünglichen where Kriterien verletzt werden. Voraussetzung ist hier natürlich, dass der View von Oracle insertable/updatable akzeptiert wird. Group by usw. wären ein NoGo.
        Gruß, defo

        Comment


        • #5
          ok, das überlege ich mir mit Views...

          vielen Dank für die Antworten!

          Comment

          Working...
          X