Alex: /(DATENBANK): Flexible Grundstruktur

Beitrag lesen

Ich nochmal.

Der Typ ist im Knoten vermerkt.

Das ursprüngliche Problem mit dem Riesen-JOIN bleibt bei dieser Lösung allerdings bestehen, wenn ich z.B. den kompletten Hierarchiebaum mit Titeln der Seiten für eine Navigation holen möchte.

Nehmen wir mal an, daß jede Seite selber weiß, wie sie heißt, d.h. sie speichert ihren Titel zusammen mit ihren anderen Daten in der entsprechenden DB-Tabelle. Beim Zusammenstellen des Baums muß dann doch wieder mit jeder Tabelle geJOINed werden, für die ein entsprechender Knoten im Baum vorhanden ist. OOP-mäßig gedacht, kann man natürlich einen abstrakten Basistyp für Seiten schaffen, der auf jeden Fall auch den Seitentitel enthält, der für alle Seiten vorhanden ist. Alle speziellen Seitentypen erben dann von diesem Basistyp. Auf DB-Ebene ist es vermutlich nicht sinnvoll, noch eine weitere Tabelle zu erstellen, die diesen Basistyp abbildet. Vermutlich sollten also eher die gemeinsamen Attribute (z.B. der Seitentitel) mit in die Knotentabelle (Hierarchiebaum) wandern.

Hmm, ich vermute fast, daß die Knotentabelle auf diesem Weg noch um einige andere Attribute erweitert wird (Erstellungsdatum etc.). Aber irgendwie mißfällt mir daran, daß die Seiten dann z.B. nicht mehr selber wissen, wie sie heißen, sondern für solche Informationen die Knotentabelle konsultieren müssen. Und doppelte Datenhaltung wäre vermutlich eine _noch_ schlechtere Idee -- das fällt schonmal als Lösung weg. Was würdest Du hier empfehlen, Vinzenz?

Grüße von Alex