Bonsoir,
 
Pour mon site Internet, je voudrais que le menu soit gérable via une interface d'administration, j'ai donc opté pour du PHP (v5) et du MySQL (v4).
 
Dans mon menu j'ai des rubriques et des entrées.
Les rubriques sont des groupes d'entrées, elles ont un nom qui leur est propre (identifiant).
Les entrées sont les "lignes" (lignes au sens de l'affichage sur le site : menu vertical) de mon menu, ce sont le plus souvent des liens.
 
Exemple :

Je pense donc qu'il me faut (au minimum) 2 tables MySQL, une pour les Rubriques, une pour les Entrées.
 
A ce point là, je ne sais pas trop quel structure donner à mes tables sachant que je voudrais éviter de devoir faire une boucle dans une boucle dans mon code PHP (d'abord un while() sur les rubriques puis, à l'intérieur, un while() sur les entrées de cette rubrique => [color=red]non[/color])
 
Alors voilà, j'essaie de trouver une solution, je réflechie aux différentes possibilités et à leur implémentation en PHP mais je ne trouve rien (tout comme sur Google)...
 
Un conseil ? Un tuyau ? Merci d'avance en tout cas.

Tu peux faire deux tables effectivement
Mais a ta place pour faire une truc aussi simple j en aurait qu une arborescente;
Id | Libelle | Niveau_arbo | Id_Papa
 
apres tu peux te debrouiller tres facilement avec ca.
 
Mais bon je repete une architecture du style
 
Rubriques
Id_Rubrique | Libelle
 
Entrees
Id_Entree | Libelle
 
Rubriques_Entrees
Id_Rubrique | Id_Entree
 
convient aussi tres bien et se manipule tres aisement

perso, j'ais opté pour 1 seule table, avec notamment une classification des rubriques pour pouvoir n'afficher que les plus importantes.. (1 table car ça me cassais les pied d'en faire plus)

Bon, j'ai finalement opté pour 2 tables ("Rubriques" et "Entrées" ) mais je me suis rendu compte que récupérer les rubriques et les entrées dans le bon ordre en une seule requète n'était pas possible avec MySQL car il n'offre pas (encore) d'équivalent du "CONNECT BY" d'Oracle

tu peux le faire avec une seule table. avec id_parent (comme cité plus haut)

Et à quoi ressemblerais la requète ? Si le CONNECT BY n'existe pas je ne vois pas comment tu veux faire.

simple jointure de la table sur elle même ?

Oui, certes, mais pour ordonner Rubriques et Entrées dans l'ordre qu'il faut (d'abord la première rubrique, puis ses entrées, ensuite la seconde rubrique, puis ses entrées, etc...) ?

ORDER BY id_papa, id ou un truc comme ça

Je me suis demandé quel interêt y'avait-il à foutre le menu dans la base de données si, au final, il est géré par des Objets (j'ai une classe "Menu", une classe "Rubrique" et une classe "Entree" ) au sein du script PHP ?
 
Je peux très bien sérialiser le tout dans un fichier (qui serait ma "Base de données non-relationnelle" ) et le charger (déserialiser) à chaque fois, ne serait-ce pas plus rapide ? Ma partie d'administration travaillerait également sur cet Objet "Menu" mais les modifications ne seraient pas écrite dans une table MySQL, à la place un fichier texte contenant la sérialisation de l'objet serait écrit dans un dossier du serveur.
 
Ainsi, ça évite toute la partie Base de données qui, au final, n'est pas très utile vu que l'ensemble des tables nécessaire pour le menu est chargé à chaque fois (ce que je veux dire c'est que cette méthode est viable -du moins je le crois- pour un menu mais qu'elle ne l'est pas pour gérer des Articles d'actualités car on ne veut pas charger l'ensemble des articles à chaque fois, et qu'on veut pouvoir faire des recherches, des tris, etc...).
 
Et après quelques tests, la méthode serialize (linéarisation) de mon objet Menu est la plus rapide et la plus simple, plus besoin de recréer l'objet Menu à chaque fois, juste besoin de le recharger.