Verwalten des "Datenzugriff mit SQL"

[Michael Schröpl]

Hi Lude,

Kann man. Aber wie stellst Du sicher, daß jede Stored Procedure nur auf diejenigen Objekte zugreift, auf die sie zugreifen 'darf' (im Sinne einer sauberen Modularisierung)?
Gegenfrage: Wie stellst Du das bei objektorientiertem Datenzugriff sicher?

Gute Frage, in der Tat.

In beiden Fällen ist eine Trennung nur dann möglich, wenn jeder 'Befugte' etwas weiß, was andere nicht wissen (z. B. eine Authentifizierung gegenüber der Datenbank - theoretisch könnte ich jede Tabellengruppe in eine separate 'Datenbank' legen und diese per Userid/Passwort und GRANT schützen).

Inwiefern nun alle Stored Procedures 'aus einer Hand' stammen oder nicht, und inwiefern selbiges für alle Module gilt, das ist natürlich eine organisatorische Frage.
Mir erscheint die Trennung zwischen Modulen logischer - um so mehr, als die hier ursprünglich genannte Namensbildung der Stored Procedures gemäß welcher Konvention auch immer eben gerade _nicht_ in dieser Dimension trennte, was Methoden eines 'Objekt-Moduls' aber schon aufgrund syntaktischer Vorgaben der Programmiersprache automatisch tun müssen (ich dulde keine name space pollution, ich adressiere Funktionen beim Aufruf generell über deren Modulname als Präfix).

Das CREATE TABLE-Statement steht ja im Quelltext des Moduls (in der Generator-Methode); dieses Modul besitzt folglich Wissen über die ansprechbaren Felder der Tabelle(n).
Würde ich dieses Wissen innerhalb eines anderen Moduls ebenfalls verwenden, dann würde ich gegen meine eigene Richtlinie verstoßen, auf die ich die Entstehung der Module überhaupt erst zurückgeführt habe: Divide et impera.

Letzten Endes erzwingt die Verwendung der Module also (fast) nichts; sie macht _mir_ das zugrundeliegende Konzept des Programmierstils nur deutlicher bewußt als die Stored Procedures.
(Welche durchaus auch ihren Anwendungsbereich haben - nämlich dann, wenn ich mit Programmen verschiedener Programmiersprachen auf dieselben Tabellen zugreifen _muß_, also die Modul-Lösung aus technischen Gründen ausscheidet ... bei Oracle hatte ich diesen Fall schon, weil ich sowohl Programme aus Oracle-proprietären Sprachen wie dessen Formular-Generator brauchte als auch solche in Pro*C.)

Viele Grüße
      Michael