Verwalten des "Datenzugriff mit SQL"

[Michael Schröpl]

Hallo Sven,

Auf diese Frage wird Michael antworten, dass er (sowas hat er unlängst mal angedeutet) grundsätzlich für ein Modul eine Tabelle mit Datenmodell verwendet, und keinerlei Joins über Tabellen unterschiedlicher Module laufen läßt.

das geht ein bißchen an dem vorbei, was ich damals geschrieben hatte.
Es ist eher umgekehrt: Mein Datenmodell ist stark objektorientiert ausgelegt, die einzelnen externen Objekte werden jeweils durch Informationen repräsentiert, die auf mehrere Tabellen verteilt sind, wobei aber Inhalte übergeordneter Tabellen beeinflussen, welche untergeordneten Tabellen dazugenommen werden müßten. Ich muß also tatsächlich zuerst die übergeordnete Tabelle lesen, um herauszufinden, womit ich hätte JOINen müssen. (Ich baue etwas Ähnliches wie die Tabs eines Browsers, aber mit stark typisierten Inhalten, welche wiederum sehr unterschiedlich detailliert parametrisiert werden, nicht so einheitlich wie die URLs in Browser-Tabs - im Sinne eines redundanzfreien Datenmodells habe ich für jeden Inhaltstyp eine separate Untertabelle usw.)
Mein Datenmodell ist wahrscheinlich ein Ausnahmefall, der sich aber genau deshalb für eine stark objektorientierte Modellierung, bei welcher die Datenbank lediglich der Datencontainer ist (und ich keine Alternative dazu habe - die Datenbank war schon vor meinem Projekt da, und ich muß _in_ihr_ ein Feature dazu bauen, das dann von einer Fremdanwendung so ausgewertet wird, als hätte sie selbst diese Daten erzeugt).

Und die objektorientierte Modellierung (mit der ich bisher gar nicht so viel Erfahrung habe, die mir aber sehr zusagt) hat eben den Vorteil der "dünnen Kanten" zwischen den Objekten - je stärker das Geheimnisprinzip ausgeprägt ist, desto einfacher ist es, die Konsequenzen nachträglicher Änderungen zu überschauen.

Viele Grüße
      Michael