nicht angemeldet
Abbildung Baumstruktur auf DB?
Hallo Allerseits,
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.
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.
Beim Zusammenfassen aller Ebenen in einer Spalte geht
die Baumstruktur verloren und muß durch einen anderen
Mechanismus ersetzt werden.
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.
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?
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 wäre dankbar für jeden Tipp.
Klaus
-
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 Kess,
ein anderer Ansatz für Dein Problem wäre eine Rekursion:
...
Beantwortet das Deine Frage ?Das weiss ich noch nicht, könnte gut sein,
da hab' ich wohl noch einiges darüber nachzudenken.
Solange die Seitennamen eindeutig sind, sollte es gehen.DB-gestützte Projektverwaltung ist eine gute Sache, wenn...
Ja, im Grunde ist das ja meine Absicht.
Wenn die (Haupt)Datenbank die Projektstruktur beschreibt und
selbst noch Hinweise zum Aufbau der einzelnen Seiten enthält,
dann gehe ich davon aus, daß der statische Teil des Projektes
'per Knopfdruck' neu generiert werden kann.
Damit wäre dann gewährleistet, daß beides übereinstimmt.
Bilde ich mir jedenfalls ein.
Mir schwant jedoch, daß ich da gedanklich schon Anwendungs-
spezifische Aktionen einbeziehe.Vielen Dank
Klaus
-
Hallo Klaus.
Das weiss ich noch nicht, könnte gut sein,
da hab' ich wohl noch einiges darüber nachzudenken.
Solange die Seitennamen eindeutig sind, sollte es gehen.Dateinamen innerhalb eines Verzeichnisses müssen immer eindeutig sein. Somit ist das gewährleistet. :-)
Viele Grüße
Kess-
Hallo Kess,
Dateinamen innerhalb eines Verzeichnisses müssen immer eindeutig sein. Somit ist das gewährleistet. :-)
Klar, das ist auch gegeben wenn Du den Pfadnahmen angibst/mitführst.
Blöd wird es nur, wenn die erste Datei in jedem Verzeichnis einfach
zwecks default INDEX heißt und die Verzeichnisstruktur implizit ist. ;-)
Das wäre also zu beachten.Viele Grüße
Klaus
-
Das weiss ich noch nicht, könnte gut sein,
da hab' ich wohl noch einiges darüber nachzudenken.
Solange die Seitennamen eindeutig sind, sollte es gehen.
Dateinamen innerhalb eines Verzeichnisses müssen immer eindeutig sein. Somit ist das gewährleistet. :-)Das ist zwar wahr, aber dennoch würde ich so etwas aus dem Entwurf der Datenbankstruktur heraushalten wollen.
Ich würde jedem Baumknoten einen internen, eindeutigen, numerischen Schlüssel geben. Eine Abbildung dieses Schlüssels auf eine externe Benennung kann ich doch in einer separaten Tabelle als 1:1-Abbildung vornehmen.Grundsätzliche Anmerkung: Keine Angst vor komplexen Joins. Zuallererst mal jede Beziehung zwischen Objekten sauber spezifizieren (1:1? 1:n? m:n?), anschließend das Relationenmodell entsprechend definieren, daraus dann die Tabellen ableiten.
Klar, die Joins werden dann eventuell komplexer, als wenn man beispielsweise alles in einer Tabelle ablegt und teilweise überflüssige Spalten hat. Letzteres rächt sich aber, wenn man *jemals* irgendwas am Modell ändern muß und dann redundante Informationen bekommen würde. Dann darf man nämlich *alles* wegwerfen und von vorne anfangen.Aus dem Kopf kann ich keinen Vortrag über Normalformentheorie halten, aber den Entwurf der Struktur einer solchen Datenbank sollte m. E. jemand vornehmen, der das gelernt hat - Raten führt hier ggf. zu entsetzlichen Fehlentscheidungen.
-
Das ist zwar wahr, aber dennoch würde ich so etwas aus dem Entwurf der Datenbankstruktur heraushalten wollen.
<g> Jetzt ist es wohl an mir zu sagen, das geht mir hier momentan zu weit ins Detail. Ich hatte nicht das Gefühl, daß Klaus gleich ein komplettes Gerüst gesucht hat. </g>
Ich würde jedem Baumknoten einen internen, eindeutigen, numerischen Schlüssel geben. Eine Abbildung dieses Schlüssels auf eine externe Benennung kann ich doch in einer separaten Tabelle als 1:1-Abbildung vornehmen.
Jepp!
Aus dem Kopf kann ich keinen Vortrag über Normalformentheorie halten, ....
<g class="noch_breiter">Brauchst Du denn einen ? Dann sag Bescheid und du bekommst ihn. Den Eindruck hatte ich allerdings nicht.</g>
Viele Grüße
Kess-
Aus dem Kopf kann ich keinen Vortrag über Normalformentheorie halten, ....
<g class="noch_breiter">Brauchst Du denn einen ? Dann sag Bescheid und du bekommst ihn. Den Eindruck hatte ich allerdings nicht.</g>Die Datenbank, aus der ich meine sämtlichen Erfahrungen schöpfe, habe ich nicht selbst gebaut, sondern jemand, der über Datenbankentwurf seine Diplomarbeit geschrieben hatte. (Ich komme nicht von der Seite der Datenbanktheorie her, sondern aus den Tiefen der Betriebssysteme - mengenorientiertes Denken habe ich auch erst lernen müssen, als ich diese Datenbank nun mal geerbt habe.)
Erst als ich Jahre später die Aufgabe bekam, in das bestehende Konzept weitere Elemente einzubauen, ist mir klar geworden, wie wundervoll sein sauberer relationaler Entwurf mir alle Möglichkeiten dazu gab.
Müßte ich eine Datenbank entwerfen, dann würde ich in der Tat erst mal ein Buch über Normalformen aus dem Schrank holen und eine Weile darin stöbern.
Es ist m. E. naiv, anzunehmen, daß ein Informatiker technisch hochwertige Lösungen aus dem Bauch erzeugen kann. (Das würde bedeuten, daß diejenigen, die über das entsprechende Thema promoviert haben oder noch mehr, alles Faulenzer waren. ;-)
-
-
-
-
-
-
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-
Hallo Tom,
:-))) Das ist ungefähr so leicht, wie eine WebSite zu bauen, die...
Ach so, wenn's denn weiter nix ist ;-)))ID ParentID FirstChildID NextID Text
Das ist ja mehrfach verkettet, kriegt man sowas je gepflegt?
Mit diesn Fragen haben wir uns auch schon beschäftigt:
Blöd, gestern hatte ich die Threads nicht gefunden.
Die Suchmaschine/Checkboxen muß ich auch noch besser kapieren.Die Frage ist, wie flexibel das Datenmodell sein muss.
Nun, derzeit muß die Flexibilität noch in direktem Verhältnis
zur Unsicherheit meiner Vorstellungen stehen.
Ob das später 'umgrenzter' wird, das möchte ich bezweifeln.Ist die Anzahl der Hierarchiesstufen in der Baumstruktur fest oder flexibel ?
Da es sich um einen realen Fall handelt, ist die Anzahl unbekannt
und wird sich über die Zeit gesehen dauernd ändern.Besteht die Anforderung, das ganze Äste beiliebig verschoben,...
Davon gehe ich aus.
Wenn alles fest und überschaubar wäre, dann würde ich vielleicht
lieber mit einer Batch oder einer CMD-Datei operieren wollen,
und, einen EDLIN hat es auch mal gegeben.Unterstützt die DB-Engine...
Derzeit gedachte ich eine konkrete DB-Engine außen vor zu lassen.
Ich habe die Vorstellung, daß gerade bei DBs, wegen ODBC und SQL,
die kompatibilität weitgehend gesichert ist.
Ich stellte mir auch vor, daß Input/Pflege und Output ziemlich
streng entkoppelt sind.Wie soll die Ausgabe erfolgen ?
Da muß ich wohl passen!
Auf 'Knopfdruck' natürlich, und hinten soll ein _ganzer Haufen_
HTML-Dateien in einem ganzen Verzeichnisbaum rausfallen.
Ready for FTP/Upload. ;-)))))Hoffentlich können Dir diese Denkanstösse bei Deiner Problemlösung helfen.
Das kann ich Dir ehrlicherweise nicht klar beantworten.
Es zeigt mir jedenfalls in welche Richtung ich zu lesen habe.Herzlichen Dank
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.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.-
Hallo Michael,
nur kurz, als 'Zeichengeben'.
Ich denke, ich habe ungefähr verstanden, was Du willst,...
Es kommt mir fast so vor als ob Du mehr verstanden hast als ich.
Nimm Dir mal den Windows-Explorer als Beispiel
Den hatte ich in diesem Zusammenhang noch nicht bedacht.
Er macht mir auch etwas Kopfzerbrechen.
Was er intern macht kann ich mir ja vorstellen, wenn ich aber
noch die graphische Ebene zu beschreiben versuche, dann
wird mir schon etwas schummrig. Beides unter einen Hut zu
kriegen, das kann ich im Moment nicht denken.
Ist vielleicht auch nicht nötig.Ich denke, Deine Angaben sind eher noch zu konkret...
Hmm, recht hast Du wohl. Da ist wohl das stille Kämmerlein angesagt.
Vielen Dank
Klaus
-
Nimm Dir mal den Windows-Explorer als Beispiel
Den hatte ich in diesem Zusammenhang noch nicht bedacht.
Er macht mir auch etwas Kopfzerbrechen.
Was er intern macht kann ich mir ja vorstellen, wenn ich aber
noch die graphische Ebene zu beschreiben versuche, dann
wird mir schon etwas schummrig. Beides unter einen Hut zu
kriegen, das kann ich im Moment nicht denken.Ich denke, in diesem Zusammenhang sind zwei Dinge zu beschreiben:
a) Was macht er? (Welcher Ausgangszustand wird mit Hilfe welcher Parameter in welchen Zielzustand transformiert? Zeichne Dir mal ein Zustandsdiagramm der Dienstleistung.)
b) Wie stellt sich die Benutzerschnittstelle dar? (Kopieren geht im Explorer beispielsweise entweder mit drag&drop oder mit cut&paste ... beides ist im Zustandsdiagramm aber dieselbe Kante, das Dialogmodell darf Redundanzen enthalten.)
Punkt a) ist relevant für den Entwurf des Datenmodells; Punkt b) ist relevant für den Ansatz der Realisierung (Programmiersprachen, Tools, graphische Standards, erforderliche Kenntnisse der Benutzer, ...).
In *keinem* dieser beiden Punkte ist übrigens abgedeckt, wie das intern realisiert wird (was Du oben wahrscheinlich gemeint hast).
Also z. B. keine Aufrufe von konkreten Systemfunktionen - *das* gehört in die Zuständigkeit des Implementierers, der das in seiner Programmdokumentation beschreiben wird.
-
-