nicht angemeldet
Hallo!
/* Beziehung zwischen Menüs und Seiten */
Ist es so, dass alle Menüpunkte in menues gelistet sind und in menu_pages die hierarchische Struktur abgebildet ist? Andererseits kann ich mir vorstellen, dass die m:n-Beziehung aussagt, welche Menüpunkte auf welcher Seite zu sehen sein soll. Wie aber spielt das mit der Hierarchie zusammen. Ein Menüpunkt kann vermutlich auf mehreren Seiten auftauchen und dann ist er mehrmals in den Nested Sets enthalten, oder nicht? Oder ist das alles ganz anders? Hier sehe ich Aufklärungsbedarf.
Es ist so, dass in cms_menues nur die "internen" Namen der Menüs und Angaben wie "Anzeigen ab" und "...bis", u.ä. Bei einer Person würde ich es am ehesten mit den körperlichen Eigenschaften vergleichen wenn du so willst. Name, Geburts- und Sterbedatum etc..
z.B.
| id | name |
-------------------
| 1 | topnavi |
-------------------
| 2 | footernavi |
-------------------
In cms_pages liegen alle Seiten (auch als nested set aber das ist ein anderes Thema) und deren Eigenschaften.
z.B.
| id | name |
------------------
| 1 | Startseite |
-------------------
| 2 | Kontakt |
-------------------
In cms_menu_pages stehen alle Seiten die einem Menü zugeordnet wurden. Die Position der Seite in ihrer "eigenen nested set" spielt dabei keine Rolle. Jedes Menü hat sein eigenes Set gespeichert in der Tabelle.
z.B.
|leftKey | rightKey | menu_id | page_id |
-----------------------------------------
| 0 | 1 | 1 | 1 |
-----------------------------------------
| 2 | 3 | 1 | 2 |
-----------------------------------------
| 0 | 1 | 2 | 1 |
-----------------------------------------
Wir haben also 2 Menüs namens "topnavi" und "footernavi".
Topnavi verlinkt auf die Seiten "Startseite" und "Kontakt".
Footernavi verlinkt nur auf die "Startseite".
Die Menü-Ids ihrerseits stehen auch in "cms_content". Die Rechte werden also über die content-Id beschafft.
und die zur übergebenen Menü-ID passen. Aber die Bedeutung dieser Bedingung erschließt sich mir nicht. Warum wird hier die Menu-ID als Parameter übergeben?
Ich hoffe, ich konnte es dir erklären?!
Das kann ich jetzt noch nicht sagen. Nur soviel: Nested-Sets-Abfragen verwenden oftmals Self-Joins und Gruppierung, so auch die Level-Query. Das mit der jetzigen gejointen und bereits gruppierten Query zu verheiraten wird eine ganz schöne Herausforderung werden.
Das Statement zu ändern ist kein Problem, nur an die DB komme ich nicht so einfach ran.
Ich wollte das Statement nur nicht ändern aus Angst etwas kaputt zu machen.
Bei der Komplexität der Query wird es wohl auf eine Array-Lösung hinauslaufen. Andererseits kann man die Komplexität mit noch mehr Komplexität augenscheinlich verringern. Die ungetestete Idee wäre, die Query in eine View zu bringen, dann wird die Anwendung des Self-Joins und der Gruppierung einfacher, als wenn man das Riesending doppelt notieren muss.
Tut mir leid, ich kann dir nicht ganz folgen. "in eine View bringen"? Und wieso doppelt?
best regards