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 :
Rubrique 1
Entrée 1 de la Rubrique 1
Entrée 2 de la Rubrique 1
Rubrique 2
Entrée 1 de la Rubrique 2
Rubrique 3
Entrée 1 de la Rubrique 3
Entrée 2 de la Rubrique 3
Entrée 3 de la Rubrique 3Je 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 => non)
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 en gros, tu me conseille de combiner les Rubriques et les Entrées dans une même table ?
C’est vrai que ça résoud le problème… mais… heu… je ne veux pas faire mon ch*eur, car rien ne t’obligeais à m’aider et je t’en remercie, mais… c’est pas un peu crade ?
OK, mais pour les champs de la table ?
Les Rubriques et les Entrées n’ont pas les même caractéristiques (seulement un nom pour les premières et un texte, une URL, un type, … pour les deuxièmes).
Je pensais tout sérialiser dans la table (un seul champ "data" qui contiendrait le retour de serialize())
Pour ma part, mon système fonctionne comme cela car une rubrique peut mener à un lien. Et le menu est mis en cache, donc ça ne pose pas de réels problèmes.
Pour ton cas, alors oui, tu as peut-être intérêt à dissocier les deux. Sauf si tu tiens à avoir des sous rubriques, auquel cas c’est la table des rubriques qui suivra le schéma suscité.
A toi de voir
Je prendrai la solution deux tables si j’avais une dissociation parfaite (exemple: sur mon site, les liens sont dans des catégories -> deux tables)
Oui, voilà c’est plutôt ça mon cas (Catégories <=> Rubriques)
Mais si j’opte pour deux tables bien dissociées, je ne vois toujours pas la requète MySQL “SELECT …” qui retournerait les lignes dans l’ordre suivant :
Rubrique 1
Entrée 1 de la Rubrique 1
Entrée 2 de la Rubrique 1
Rubrique 2
Entrée 1 de la Rubrique 2
Rubrique 3
Entrée 1 de la Rubrique 3
Entrée 2 de la Rubrique 3
Entrée 3 de la Rubrique 3
Ebauche de la requète :
SELECT *
FROM rubriques R, entrees E
WHERE
E.rub_id = R.id AND
??
ORDER BY R.ordre, ??
Cela sert à l’affichage d’une hierarchie lorsqu’on dispose, dans une meme table, de 2 colonnes traduisant la relation niveau inférieur - niveau supérieur.
(La variable LEVEL est définie automatiquement)
Selon mes cours d’Oracle
Saluton,
Je me pose toujours la même question : quelle sera la variabilité de ces items de menu du site web, horaire, quotidienne, hebdomadaire, mensuelle, annuelle ?
Bref, est-ce que ça vaut vraiment le coup de mobiliser toutes ces ressources pour construire dynamiquement un menu finalement assez statique ?
Sans-Nom > La variable LEVEL est un plus des requètes hierachiques, l’utilisation de “CONNECT BY” en elle même permet de “trier des enregistrements en utilisant des notions d’arborescence inter-enregistrement”.
Maljuna Kris > Je suis bien d’accord, mais le but est de permettre à quelqu’un de modifier le menu sans qu’il n’ait à apprendre l’HTML et/ou le PHP.
Manquerait plus qu’il soit plus malléable (j’aimerai bien savoir comme déplacer le répertoire des données ailleurs que dans program files, histoire de pas tout perdre).
Ah, et la doc est passablement à chier, et pgmyadmin est nul (bon tu me diras, y a l’exécutable Windows, mais bref)
+1 Je me suis rendu compte que je pouvais le faire avec MySQL et c’est vrai que c’est très pratique de pouvoir foutre le dossier de données sur son disque de données (et non pas sur son disque de programmes)
