Verwalten des "Datenzugriff mit SQL"

[Michael Schröpl]

Hi Lude,

Habe ich Dich tendenziell richtig verstanden?

Ja.

Welche Strukturhierarchie sollten die Objekte?
Soll sowas wie eine Baumstruktur 'rauskomen?

"Soll" klingt so, als könntest Du es erzwingen - ich denke, das kann man nicht, das kommt auf die Natur der zu modellierenden Daten an. Bei mir ist das schon im theoretischen Sinne ein (vierstufiger) Baum, der ziemlich "mit Gewalt" in _eine_ relationale Tabelle gequetscht wurde ... das, was ich an Tabellen selbst angelegt habe, ist m. E. 'natürlicher', existiert neben dieser einen Tabelle und muß ständig in diese übersetzen, weil deren Inhalt zu signifikanten Teilen außerhalb meiner Kontrolle periodisch neu generiert wird und dabei bestimmte Teile seines Inhalts ändern kann ... ich sagte ja, mein Datenmodell sei ein Extremfall.

Ist der Overhead nicht _immens_, wenn man sich Abfragen mit beispielsweise 8 Joins vorstellt?

Ja, ist er.

Aber ich habe nie ausgeschlossen, daß ein Objekt nicht auch eine _Gruppe_ thematisch verwandter Tabellen, die selbst nur untereinander geJOINed werden, nicht jedoch mit anderen zusammen, kapselt. (In mySQL würde ich für eine solche Gruppe ggf. sogar eine separate "Datenbank" anlegen ...)

• Kann man diese "Datenzugriffs-ObjektStruktur" nicht auch mit SPs, die sich gegenseitig aufrufen, abbilden?

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)?

Das Geheimnisprinzip ersetzt guten Willen durch Kontrolle.

Viele Grüße
      Michael