Forum Clubic

[SQL] Structure tables MySQL pour menu de Site Web - ch. conseil pour optimisation de requète

Logiciel Programmation
#1

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 :

  • 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.

#2

Une idée me vient à l’esprit, il faudrait essayer pour voir si elle est réalisable.

tu fais une seule table qui contient (au minimum)

rubrique_id, parent_id, nom, …

rubrique_id étant l’identifiant unique.
parent_id étant l’ID de la rubrique parente (logique nan ? ^^)

si la rubrique est au premier niveau tu lui met un parent_id = 0

ensuite tu fais une requet sur ta table avec

ORDER BY parent_id, rubrique_id

(Tu peux même rajouter un champ pour changer l’ordre du menu)

De cette façon tu arrive facilement à avoir plus que 2 niveaux, tu n’a qu’une table, et ça me semble assez simple à gérer.

voilà voilà :slight_smile:

#3

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 ?

#4

C’était une idée que j’avais. Je ne garanti pas de la proporeté du truc et de la faisabilité.

à toi de voir si ça te convient :wink:

#5

Comme dit NeqO, tu peux le faire en une seule table :

menu_id primary key
parent_id index NULL
menu_title

Cela t’offre l’avantage de la récursivité dans le menu (en gros des sous rubriques, etc).

Si parent_id IS NULL, c’est que tu as une rubrique.

#6

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())

#7

Cela dépend.

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 :slight_smile:

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)

#8

une seule table wouaip genre

id nom type
xx score rubrikTotal
xx newz rubrikActu

tu select suivant ton menu avec la clause type et en order by asc;

#9

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, ??
#10

Tout ne se résoud pas en SQL.

SELECT rubrique_id AS id, rubrique_title AS title
FROM rubrique
ORDER BY rubrique_order ASC

puis pour chaque rubrique :
SELECT entry_id AS id, entry_title AS title
FROM entry
WHERE rubrique_id = ${rubrique[‘id’]}
ORDER BY entry_order ASC

Etc.

#11

Snif… J’aurai voulu trouver le truc en une seule requète :slight_smile:

Edit : Maintenant, je sais ce que je cherchais : l’équivalent MySQL du “CONNECT BY PRIOR” d’Oracle :slight_smile:

#12

Cela fait quoi ça, tiens?

#13

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 :slight_smile:

#14

En gros ce que tu peux faire en foutant un champ level, représentant la hauteur de l’arbre (“hierarchie”) donc?

#15

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 ?

#16

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.

#17

ce post juste pour dire que postgresql sait également faire connect by [:siffle]

[:shy]

#18

Ouaip pgsql

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)

#19

+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)

#20

Lors du démarrage de la base de données tu peux lui spécifier le répertoire de données[1], la doc au contraire je la trouve pas mal :heink: (ici).

pgmyadmin -> connais pas. j’utilise pgadmin :neutre:

[1] http://docs.postgresqlfr.org/8.1/runtime-c…-locations.html