[SQL + PHP] Oneindige submenu's

[Joen]

Geachte mede tweakers,

Ik vind dit voor mij zelf een ietwat lastig vraagstuk en had dus ook geen idee hoe ik eventuele zoekopdrachten hier voor exact zou moeten definiëren, dus ik stel gelijk de vraag hier maar in een nieuw topic.

Ik zou graag voor een websiteproject voor mijn aankomende stageadres een soort menustructuur willen gebruiken dat oneindig uitklapbaar is, maar ik vraag me af hoe ik mijn query's daar voor moet gaan opstellen e.d.

Om mijn vraagstelling iets duidelijker te maken heb ik even 2 tabelstructuren + enkele gegevens voor mijn database gemaakt.
Je ziet dus dat in de tabel 'menu' alle menu-items staan en dat auotmatisch submenu's niet tussen de hoofdmenu's verschijnen, maar dat tijdens het laden van de hoofdmenu's wel automatisch eerste de pagina's uit de tabel 'pagina' worden geladen en daar onder de submenu's.
Een hoofdmenu wordt gekenmerkt door de waarde 0 (nul) in het veld 'hoofdid'.

En omgekeerd zou ik het ook handig vinden om te weten hoe ik terug kan rekenen vanuit een bekende pagina-id in welke submenu's en hoofdmenu die staat, maar dat valt allicht dan nog zelf uit te vogelen.

De tabellen:

code:

TABEL menu
+----+---------+---------+-----------------------------+
| id | hoofdid |volgorde | naam                        |
+----+---------+---------+-----------------------------+
|  1 |       0 |       1 | Algemeen                    |
|  2 |       0 |       2 | Contact                     |
|  3 |       1 |       1 | Informatie                  |
+----+---------+---------+-----------------------------+

code:

TABEL paginas

+----+--------+----------+--------------------------+---------+-----------------+-----------------------------+-------------------+--------------------+
| id | menuid | volgorde | titel                    | include | includebestand  | tekst                       | tijdstipgewijzigd | tijdstiptoegevoegd |
+----+--------+----------+--------------------------+---------+-----------------+-----------------------------+-------------------+--------------------+
|  1 |      1 |        1 | Wie zijn wij?            |       0 |                 |Op deze pagina lees je       | 20040111213800    | 20040111213800     |
|    |        |          |                          |         |                 |binnenkort wie we zijn.      |                   |                    |
|  2 |      2 |        1 | Stuur ons een e-mail     |       1 | inc/email.php   |                             | 20040111214000    | 20040111214000     |
|  3 |      1 |        2 | Wat zijn onze doelen?    |       0 |                 |Lees hier over onze doelen   | 20040111214700    | 20040111214700     |
|  4 |      3 |        1 | Brochure                 |       0 |                 |Vraag een brochure aan door  | 20040111215200    | 20040111215200     |
|    |        |          |                          |         |                 |een e-mail te sturen naar    |                   |                    |
|    |        |          |                          |         |                 |[e-mail]          |                   |                    |
+----+--------+----------+--------------------------+---------+-----------------+-----------------------------+-------------------+--------------------+

De geografische structuur vertaling van de tabellen en gegevens zoals ik het in gedachten heb:

code:

ROOT
 |
 +-- Algemeen                     (menu id 1, volgorde 1)
 |      |
 |      +-- Wie zijn wij?         (pagina id 1, volgorde 1)
 |      +-- Wat zijn onze doelen? (pagina id 3, volgorde 2)
 |      |
 |      +-- Informatie            (menu id 3, submenu van 1, volgorde 1)
 |              |
 |              +-- Brochure      (pagina id 4, volgorde 1)
 |
 +-- Contact                      (menu id 2, volgorde 2)
        |
        +-- Stuur ons een e-mail  (pagina id 2, volgorde 1)

Kan iemand mij adviseren in de te gebruiken tabelstructuur (als de mijne niet werkbaar is volgens jou) en de te gebruiken query's?

[BrZ]

Met jouw tabelstructuur zal het in ieder geval goed werken. Het heeft echter wel een nadeel, als je een redelijk diepe structuur hebt zul je vanwege de recursieve functies die je zal moeten gaan gebruiken erg veel (relatief simpele) queries nodig hebben.

[henkleerssen]

eeuh ik heb hier in dhtml het een en ander met menustructuur gedaan. Is misschien handig om er bij te gebruiken..
ennuh Ik weet het .. je moet ff dynamisch wat variabelen vullen met PHP en bijpassende queries runnen, wat nog ff het meeste werk is natuurlijk..

[man-o-script]

ik zou denk ik alles in 1 tabel gooien zodat alle menuitems een eigen (auto) id krijgen.
Daarna aangeven per menuitem wat zijn 'parent' is.

Dus iets als:

PHP:

TABEL menuitems

+----+--------+----------+--------------------------+
| id | parent | volgorde | titel                    |
+----+--------+----------+--------------------------+
|  1 |      0 |        0 | Algemeen               |
|  2 |      0 |        0 | Contact                  |
|  3 |      1 |        1 | Wie zijn wij?           |
|  4 |      1 |        2 | Wat zijn onze doelen?    |
|  5 |      1 |        3 | Informatie              |
|  6 |      5 |        0 | Brochure                 |
+----+--------+----------+--------------------------+

zo zou je in principe een oneindig menu met subitems kunnen bouwen lijkt me

[BrZ]

man-o-script schreef op 11 januari 2004 @ 22:31:
ik zou denk ik alles in 1 tabel gooien zodat alle menuitems een eigen (auto) id krijgen.
Daarna aangeven per menuitem wat zijn 'parent' is.

Dus iets als:

PHP:

TABEL menuitems

+----+--------+----------+--------------------------+
| id | parent | volgorde | titel                    |
+----+--------+----------+--------------------------+
|  1 |      0 |        0 | Algemeen               |
|  2 |      0 |        0 | Contact                  |
|  3 |      1 |        1 | Wie zijn wij?           |
|  4 |      1 |        2 | Wat zijn onze doelen?    |
|  5 |      1 |        3 | Informatie              |
|  6 |      5 |        0 | Brochure                 |
+----+--------+----------+--------------------------+

zo zou je in principe een oneindig menu met subitems kunnen bouwen lijkt me

Kan inderdaad ook. Op jouw manier is het menu makkelijker te generen, maar het bepalen welk onderdeel alleen een subcategorie is en welke echt een pagina wordt iets moeilijker. Bij de TS z'n manier is het maken van het menu juist weer iets moeilijker.

Denk zelf dat ik voor de 1e manier zou gaan. Je hebt iig nog een 2e tabel met pagina's nodig, en op jouw manier zou je bv 2 pagina's aan "Wie zijn wij?" kunnen koppelen, terwijl dat niet de bedoeling is (ok, kan je natuurlijk wel voorkomen door het menuid van een pagina unique te maken, maar dat is ook niet echt een nette oplossing vind ik)

[man-o-script]

Het ligt er natuurlijk ook maar net aan of je een CMS'je erachter maakt of niet en hoe deze gaat werken, moet je ook wel rekening mee houden lijkt me.

Denk dat het meer komt door mijn tik om zo min mogelijk tabellen te gebruiken

[Joen]

OK, ik snap dus dat beide manieren een aantal nadelen hebben, maar mijn hoofdvraag (die helaas onbeantworod is gebleven) welke query's zal ik daar voor moeten uitvoeren?
Ik heb enig vermoeden dat dit nl. ingewikkeld wordt en met een aantal voormij onbekende SQL functies.

man-o-script schreef op 11 januari 2004 @ 22:40:
Het ligt er natuurlijk ook maar net aan of je een CMS'je erachter maakt of niet en hoe deze gaat werken, moet je ook wel rekening mee houden lijkt me.

Denk dat het meer komt door mijn tik om zo min mogelijk tabellen te gebruiken

Er komt allicht een CMS bij ja, maar een relatief eenvoudige van opzet.

[ Voor 44% gewijzigd door Joen op 11-01-2004 22:43 ]

[man-o-script]

iniedergeval een gezellige JOIN lijkt me,
is zat over te vinden in de search ook denk ik.


Ook al is die eenvoudig van opzet, zou toch even nadenken over hoe je dat makkelijk kunt opzetten.
Heb vaak genoeg achteraf nog een hele database om moeten gooien toen ik aan het CMS begon

[ Voor 42% gewijzigd door man-o-script op 11-01-2004 22:46 ]

[Joen]

Ik heb toevallig net een toets gehad waar een heel klein beetje over JOINS werd gesproken, mar het is totaal niet mijn sterkste kant
En ene JOIN is toch om gegevens uit een andere tabel samen te voegen met de gegevens in de ene tabel? Met mijn menu gaat het slechts om 1 tabel in principe.

[_-= Erikje =-_]

ikzelf gebruik meestal voor dit soort dingen niet een functie die steeds een query uitvoert, maar laad van te voren de benodigde gegevens in een php array en geef dat array mee met de functie, zo maak je niet 10000 queries, maar ben je met 1 query klaar.

[BrZ]

_-= Erikje =-_ schreef op 11 januari 2004 @ 22:47:
ikzelf gebruik meestal voor dit soort dingen niet een functie die steeds een query uitvoert, maar laad van te voren de benodigde gegevens in een php array en geef dat array mee met de functie, zo maak je niet 10000 queries, maar ben je met 1 query klaar.

De vraag is wat sneller is. 1x alles uit de tabel halen en met PHP je array de hele tijd doorzoeken, of elke keer 1 row opvragen uit de dbase, wat met deze structuur en een goede index echt heel weinig tijd kost. Daarnaast is een oneindig menu natuurlijk erg relatief, dieper dan 4 of 5 stappen zal je zelden komen.

De queries zijn trouwens echt heel eenvoudig, meer dan "SELECT id, naam FROM menu WHERE hoofdid=$id ORDER BY volgorde" heb je niet nodig, alleen zul je dit dan per menu-item moeten herhalen.

[ Voor 13% gewijzigd door BrZ op 11-01-2004 23:06 ]

[man-o-script]

Ikzelf gebruik ALTIJD een benchmark function om het aantal MySQL queries te tellen en het aantal sec.
Dan kun je het eventueel nog vergelijken als snelheid echt een issue is.
Hou je een beetje inzicht in waar je mee bezig bent.
Maar is een beetje offtopic

[ Voor 17% gewijzigd door man-o-script op 11-01-2004 23:07 ]

[nescafe]

En in ieder topic met trees komt dit artikel minstens één keer naar voren:
Storing Hierarchical Data in a Database

Waarbij met name pagina 2 een manier laat zien waarbij je niet zoveel queries nodig hebt om je informatie op te vragen.

[BrZ]

nescafe schreef op 11 januari 2004 @ 23:16:
En in ieder topic met trees komt dit artikel minstens één keer naar voren:
Storing Hierarchical Data in a Database

Waarbij met name pagina 2 een manier laat zien waarbij je niet zoveel queries nodig hebt om je informatie op te vragen.

Hmm, erg interessante manier
Alhoewel ik denk dat het in dit geval, met een relatief kleine hoeveelheid data niet de moeite waard is om het op die manier te implementeren: stuk ingewikkelder, kost dus veel meer tijd om te maken, terwijl je er waarschijnlijk nauwelijks voordeel uit haalt.

[Joen]

In ieder geval bedankt voor ieders reacties.
Ik zal de verschillende manieren eens gaan uitproberen en kijk wat voor mij uiteindelijk het meest werkbare is.
Mijn stage begint volgende week maandag, dus vanaf dan ga ik er mee aan de slag waarschijnlijk.
Ik zal evt. verdere vragen hier over weer in dit topic dan gaan stellen.

[JaQ]

Zelf gebruik ik over het algemeen phplayers voor treemenu's. Het grote voordeel van een bestaande class gebruiken is dat je niet dagen je hoofd zit te breken op database structuren of php debuggen. (en waarom zou je geen gebruik maken van de open source community)

Allicht is het leuk om eens naar te kijken, als is het alleen maar om te ontdekken hoe zij e.e.a. hebben opgelost?

[Joen]

Dat klinkt interessant, die zal ik zeker tijdens mijn stage even gaan bestuderen.

[Sosabowski]

Ziet er zeker interessant uit die 2e optie maar.....
volgens mij is het niet mogelijk dat een parent meer dan 2 childs heeft. De optie die man-o-script geeft kan dit wel.
Vooral bij submenu's maar ook bij bv een forum kan ik me voorstellen dat dit een grote beperking is.

[faabman]

als je er een cms van gaat maken dan zou ik 1 tabel gebruiken voor de menuitems en 1 tabel voor de content

dus:
tbl_menu
menuID
parentID


tbl_content
contentID
menuID

op die manier kan je dus meerder contentitems koppelen aan 1 menuitem en kan je delen van je pagina's klaar hebben en niet actief (1 pagina is immers opgebouwd uit meerdere records) wat ik zelf heb geimplementeerd is een actief_van / actief_tot optie zodat je een actie die in maar loopt al in januari kan aanmaken en automagisch zichtbaar laat worden in januari...

[ Voor 21% gewijzigd door faabman op 12-01-2004 21:05 ]