Hallo Klaus,

ein anderer Ansatz für Dein Problem wäre eine Rekursion:

Dazu brauchst du je Seite zwei Spalten: Seite und Parent
Lediglich die Startseite besitzt keinen Parent.

Beispiel:
index.html - NULL
Topic1.html - index.html
Topic2.html - index.html
Topic2_1.html - Topic2.html
...

Die erste Angabe ist dabei der Dateiname, die zweite der Verweis aud die übergeordnete Datei.
So entsteht eine saubere Baumstruktur.
Gute Datenbanken bieten spezielle Befehle zur Abfrage solcher Rekursionen. Bei einfachen Mußt du die entsprechenden Schleifen eben selbst programmieren.

Beantwortet das Deine Frage ?

DB-gestützte Projektverwaltung ist eine gute Sache, wenn sie sauber durchgezogen wird.
Oft sieht es so aus, daß statische Dokumente vorliegen und die Sturktur zur Dokumentation und Wartung manuell in die Datenbank eingepflegt wird. Davon kann ich leider nur abraten. Beim ersten Streß bleibt die Pflege der Datenbank liegen und wird nur verspätet nachgeholt. Irgendwann ist die Datenbank hoffnungslos veraltet.
Projektmanagement - bei größeren Projekten absolut sinnvoll - und die Pflege der Seiten sollten Hand in Hand arbeiten, am besten automatisch. Dabei ist es gleichgültig, ob dahinter eine Datenbank steht oder eine andere Software. Das kommt auf die speziellen Anforderungen an.

Viele Grüße
Kess

Hallo Klaus

mir geht die Frage durch den Kopf, wie man denn am
gescheitesten eine Baumstruktur, wie sie bei der
Beschreibung einer Seiten-/Sitestruktur entsteht,
auf eine Datenbank abgebildet kriegt.
Die Datenbank soll auch noch zusätzlich Backan-
weisungen für die Seiten und die Navigation enthalten.
Auch die Verzeichnisstruktur sollte enthalten sein.

Mit diesn Fragen haben wir uns auch schon beschäftigt:

als Ausgangsfrage: <../../sfarchiv/1999_4/t07098.htm>

und als weiterführende Diskussion: <../../sfarchiv/1999_4/t07110.htm#a35669>

Die Frage ist, wie flexibel das Datenmodell sein muss.
Ist die Anzahl der Hierarchiesstufen in der Baumstruktur fest oder flexibel ?
Besteht die Anforderung, das ganze Äste beiliebig verschoben, ev. auch kopiert werden müssen ?
Unterstützt die DB-Engine Stored-Procedures oder lassen sich die Verwaltungsaufgaben (rekursives Kopieren, ...)  über ein Perl-Skript lösen ?
Wie soll die Ausgabe erfolgen ?
usw...

Hoffentlich können Dir diese Denkanstösse bei Deiner Problemlösung helfen.

Grüsse
Tom

mir geht die Frage durch den Kopf, wie man denn am
gescheitesten eine Baumstruktur, wie sie bei der
Beschreibung einer Seiten-/Sitestruktur entsteht,
auf eine Datenbank abgebildet kriegt.
Die Datenbank soll auch noch zusätzlich Backan-
weisungen für die Seiten und die Navigation enthalten.
Auch die Verzeichnisstruktur sollte enthalten sein.

Es ist leider so, daß für einen optimalen Datenbankentwurf *alle* Eigenschaften des zu erstellenden Systems bekannt und im Detail beschrieben sein müssen.
Ich denke, ich habe ungefähr verstanden, was Du willst, bin aber keineswegs in der Lage, auch nur konkrete Tips zu geben, wie Du Deine Relationen aufbauen solltest, weil einfach zu viele Freiheitsgrade vorliegen.

Im ersten Ansatz würde ich das ja als Matrix verstehen,
mit Spalten für die (Pfad)Ebenen und je einer Zeile
pro Seite.
Der Nachteil wird schnell offensichtlich, joins würden
immer nur ebenenweise funktionieren, das Ding würde
ziemlich groß und durch sehr viele leere Felder charak-
terisiert.

Du siehst selbst, daß ein Entwurf, der für eine Operation prima aussieht, für die andere eine Katastrophe sein kann.
Genau deshalb braucht der Designer eben *alle* Operationen, die durchgeführt werden können sollen. Fehlt auch nur eine, dann kann der Entwurf wertlos sein.

Aus Schriftstücken kennt man Ordnungssysteme bzw.
Kapitelnummerierungen der Art 1.  1.1.   1.1.1.   ...
Sowas könnte man einführen, ist aber wohl nicht so furchtbar
doll gut für eine intuitive Bedienung und Pflege geeignet.

Das kommt auf die auszuführenden Operationen an. Wenn Du beispielsweise Deine Baumstruktur nie mehr änderst, dann ist so etwas prima - deshalb verwendet man es ja auch in Büchern.
Hast Du aber Einfügungen, Löschungen oder gar Verschiebungen von Teilbäumen, dann müßtest Du große Teile des gesamten Baums umnumerieren.
Je dynamischer Dein Baum ist, desto zwingender sind relative Adressierungen, die erst beim Zugriff aus der Position des Knotens im Baum berechnet werden.
Generell würde ich davor warnen, externe syntaktische Elemente in die Adressierung der Datenbankstruktur einzubrennen. Mach Dir Deine internen Primärschlüssel numerisch-eindeutig, dann hast Du schon mal eine Abstraktionsebene Abstand von der bösen realen Welt, die sich immer dann ändert, wenn man das gar nicht brauchen kann.

Aus der Softwaretechnik sind verkettete Listen bekannt.
Die Datenbank könnte implizit entsprechend aufgebaut sein.
Aber wie sieht es dabei mit Bedienung und Pflege aus?

Das kommt auf die Operationen an, die als "Pflege" anfallen.
Nimm Dir mal den Windows-Explorer als Beispiel - das ist ein Programm, welches eine Baumstruktur pflegt. Überlege Dir, inwiefern Du dieselben oder mehr oder weniger Operationen brauchst als er, und überlege Dir, ob Dir seine Bedienung in den betreffenden Punkten intuitiv vorkommt.
Einen solchen Editor zu schreiben kann natürlich ein Haufen Arbeit sein ... allerdings: Baumnavigation ist vom Konzept her rekursiv, und rekursive Algorithmen tendieren dazu, mit relativ kompaktem Code und hoher Wiederverwendbarkeit realisiert werden zu können. Es wird also eher intellektuell komplex als programmtechnisch kompliziert.

Hat jemand von Euch Erfahrung mit datenbankgestütztem
Management umfangreicherer Web-Projekte?
Meine Überlegungen bewegen sich noch in einem recht
abstrakten Raum, unabhängig von bestimmten Anwendungen
bzw. Programmen. Es erscheint mir auch sinnvoll diese
Fragestellung erstmal auf dieser Ebene zu kapieren.

Ich denke, Deine Angaben sind eher noch zu konkret (nämlich auf ein Produkt namens "Datenbank" bezogen).
Geh mal davon aus, daß Du alle bekannten komplexen Datenstrukturen mit einer normalen Datenbank auch irgendwie darstellen kannst, und arbeite erst mal die Semantik Deiner Struktur aus.
Brauchst Du einen Baum, den Du zunächst einmal nur linksrekursiv abwärts traversieren mußt? Okay, das kann dann eine zweifach verkettete Liste sein (nächster Bruder, erster Sohn). Mußt Du im Baum auch aufwärts navigieren? Aha, der dritte Verweis ist fällig, nämlich zum Vater. Mußt Du lokal Einfügen bzw. Löschen? ... und so weiter.

Es hilft wirklich nur, erst einmal sämtliche Operationen zu spezifizieren und dann eine relationale Zerlegung der vorliegenden Daten zu schreiben.
Ändert sich die Anzahl der Operationen, dann ist eine Änderung des Entwurfs der Datenbankstruktur in vielen Fällen die zwingende Folge. Deshalb empfiehlt es sich, in den Entwurf ggf. auch Operationen mit einzubeziehen, deren spätere Notwendigkeit noch nicht endgültig feststeht. Ein Entwurf, der mehr Operationen berücksichtigt, als benötigt werden, ist wahrscheinlich nicht optimal (weil z. B. Verwaltungsinformationen für die zusätzlichen Operationen mit gepflegt werden müssen, auf die dann tatsächlich noch niemand zugreift), aber er ist kompatibel gegenüber den vorgesehenen Änderungen, und die Gefahr, daß großräumige Änderungen mit Auswirkungen auf *alle* Anwendungen anfallen, wird dann sehr gering.