CMS-Navigation Problem

K

Kuscheltier

Guest
Hey und Hallo,

ich grübel seit Tagen jetzt schon über dem Problem, wie ich innerhalb eines CMS-Systems am betsen die Navigationselemente integriere...

Die Grundstruktur des eigentlichen Contentbereiches habe ich mir folgendermaßen überlegt.

Für jede Seite die abgerufen wird, wird in einer Tabelle ein Datensatz erfasst der die grundlegenden Daten (Name, ID, Recht zur Anzeige, Keywords/ Beschreibung für Suchmaschinen, ...). Auf Basis dieses einen Datensatzes werde ich aus den weiteren Tabellen die den eigentlichen Content lesen und zur anzeige bringen.

Wobei ich aber irgendwie keine gute Idee habe ist die Integration der Navigation die ich natürlich anzeige lasse.

Die Navigation wollte ich auf jedenfall über mehrere Hirachien realisieren, die denn nach und nach erscheinen wenn die jeweilige Übergeordnete "Kategorie" aufgerufen wird. Wie ich mir das vorstelle wäre zum Beispiel folgende:

WebDevelopment
- PHP
-- Tutorials
-- Scripts
- Perl
- HTML
-- Grundlagen
--- Tabellen
--- Frames
- JS

Was ich aber vermeiden will ist einfach der Punkt, dass ich die Daten redundant in der Datenbank speicher. Die jeweiligen Navigationselemente will ich auf Basis der aufgerufenen Seite denn dynamisch auslesen. WEas aber auch auftreten kann ist jener Punkt, dass zu verschiedenen Seiten die gleichen Navigationselemente gehören.

Würde mich freuen wenn jemand von euch vielleicht eine Idee hat, wie ich dieses Navigationsproblem am effektivsten umsetzen/ realisieren kann/ könnte. Mir gehts hier jetzt aber nicht um eine fertige Lösung sondern ein Konzeot wie ich die Daten in der Datenbank speicher und wie die Logik der benötigten Scripte im groben aussehen könnte...

 
Hallo.

QUOTE (Kuscheltier @ Fr 25.11.2005, 16:41)[...]
Was ich aber vermeiden will ist einfach der Punkt, dass ich die Daten redundant in der Datenbank speicher. Die jeweiligen Navigationselemente will ich auf Basis der aufgerufenen Seite denn dynamisch auslesen. WEas aber auch auftreten kann ist jener Punkt, dass zu verschiedenen Seiten die gleichen Navigationselemente gehören.
[...]

Das sind etwas zu wenig informationen, um es wirklich Deine Frage verstehen zu können, auch verstehe nicht genau, was Du ausdrücken möchtest. Warum sollten sich Redundanzen auftun bei der Speicherung in der Datenbank, sowas ist im Grunde doch einfach zu realsieren.



CODE cms_menu:
+----+-----------+-----------+
| id | menupunkt | parent_id |
| -- | | - - - - - |
+----+-----------+-----------+
\__________________/


  • die id ist der Primärschlüssel
  • in menupunkt sind die weiteren Daten zusammengefasst (linkname, link, sortierung usw.; diese liegt in deinen Ermessen)
  • parent_id ist der Fremdschlüssel und wird gesetzt, wenn über diesen Menüpunkt, ein anderer Menüpunkt existiert - sprich ist dieser NULL, ist er das oberste Element in der Navigation. Ansonsten steht hier die id des Primärschlüssels der gleichen Tabelle, von welchen Menüelement, dieses Menüelement ein Unterpunkt ist. Somit lässt sich theoretisch das Menü beliebig weit verschachteln (ist jedoch nicht unbedingt sinnvoll)
Programmiertechnisch möchte ich das nicht alles durchkauen, denn das ist mehr arbeit als nur die Grundstruktur sich zu überlegen und die Tabelle eben anzulegen. Auch kommt es hier wieder ganz darauf an, wie das System funktionieren soll.


Diese Lösung ist speziell auf MySQL zugeschneidert und wird vermutlich nur mit einer MyISAM-Tabelle funktionieren. InnoDB erlaubt, nach meinen Informationen, keine Verknüfung innerhalb der eigenen Tabelle.



MfG Sascha Ahlers

PS: Ich hoffe, dass es so verständlich ist.
 
QUOTE WEas aber auch auftreten kann ist jener Punkt, dass zu verschiedenen Seiten die gleichen Navigationselemente gehören.


wenn ich das richtig verstehe meist du , das z.B. der Menüpunkt HTML in verschiedenen Kategorien auftauchen kann,
-Tutorials
-- HTML
-- Javascript
...........

- Scripte
-- Javascript
-- HTML
....

wobei aber bei beiden Menüpunkten HTML je unterschiedliche Inhalte erscheinen?
da würde ich auch den Vorschlag von Sascha Ahlers nutzen


CODE cms_menu:
+----+-----------+-----------+
| id | menupunkt | parent_id |
| -- | | - - - - - |
+----+-----------+-----------+

das könnte dann mit Daten so aussehen.

1 | Tutorials | 0
2 | HTML | 1
3 | Javascript | 1
4 |Scripte | 0
5 | Javascript | 4
6 | HTML | 4

In dem Fall steht zwar die Bezeichnung HTML und auch Javascript mehrmals in der Tabelle, aber ich denke mal das man dies getrost ignorieren kann.

Lediglich bei einem extrem umfangreichen Menü, bei dem vielleicht verschiede Begriffe 10 mal und öfter vorkommen würde es sich eventuell lohnen die Bezeichnungen in einer Extra Tabelle abzulegen so ds jede Bezeichnung nur noch einmal vorhanden ist...
 
QUOTE (Metaman @ Fr 25.11.2005, 19:16)[...]
Lediglich bei einem extrem umfangreichen Menü, bei dem vielleicht verschiede Begriffe 10 mal und öfter vorkommen würde es sich eventuell lohnen die Bezeichnungen in einer Extra Tabelle abzulegen so ds jede Bezeichnung nur noch einmal vorhanden ist...

Nun, damit wären wir bei den Normalisierungsformen und Preformence, Sinn könnte es machen, nur wieviel, dass ist eine andere Frage. Aber ich habe nicht umsonst geschrieben, dass er sich überlegen kann, wie er die Datenbank dazwischen aufbauen möchte.
Immerhin kann die Tabelle auch so (siehe unten) aussehen und dann stellt sich die Frage, ob es wirklich sinnvoll ist, diese eine Spalte in eine andere Tabelle auszulagern. Selbst wenn hierbei eine Wiederholung des Wertes auftaucht. Genauso, wie man sich (Bspw.) die Frage stellen kann, ob es wirklich sinnvoll ist den Straßennamen und die Hausnummer getrennt zu speichern. Beide Felder müssen einen Text in variabler Länge speichern können, da führt kein Weg dran vorbei (vermutlich wird hierbei varchar verwendet), nur wie es letztendlich gemacht wird, dass hängt vom Verwendungszweck ab.

Hier könnte immerhin, nur wegen dieses einen Feldes eine weitere Abfrage an eine andere Tabelle (bei MySQL bedeutet dies auch an eine andere Datei) gestellt werden.
Auch ist der Programmieraufwand etwas größer, wenn man möchte, dass jedes Feld später auch wieder umgenannten werden kann. Ohne das der Anwender groß etwas beachten muss - oder auch ändern muss in weiteren Arbeitsschritten -, damit die anderen Einträge nicht auch noch umbenannt werden.


Was letztendlich wirklich sinnvoll ist, muss individuell entschieden werden.



CODE cms_menu:
+----+------------+---------+---------+-----------+
| id | name | link_id | sort_id | parent_id |
| -- | | | | - - - - - |
+----+------------+---------+---------+-----------+
| 1 | Tutorials | 20 | 1 | 0 |
| 2 | HTML | 21 | 2 | 1 |
| 3 | Javascript | 23 | 1 | 1 |
| 4 | Scripte | 27 | 2 | 0 |
| 5 | Javascript | 32 | 2 | 4 |
| 6 | HTML | 36 | 1 | 4 |
+----+------------+---------+---------+-----------+




MfG Sascha Ahlers
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben