nicht angemeldet
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.