Menu Multilingue en base de donnée à 2 ou 3 niveauxRésolu

Question

Bonjour, Je veux créer un menu multilingue en base de donnée à 2 ou 3 niveaux présenté sous cette forme : -Catégorie1 -Catégorie2 -Sous_Catégorie1 -Sous_Catégorie2 -Présentation -Documentation -Sous_Catégorie3 -Présentation -Documentation -Sous_Catégorie4 -Présentation -Documentation -Sous_Catégorie5 -Catégorie3 ...etc... J'ai un peu de mal avec le procédé à utiliser... - Faut-il créer une seule table avec un niveau hierarchique pour chaque catégorie et un "parentId" référent ? - Ou une table pour chaque niveau hierarchique en faisant une jointure ? - Comment on gère le multilingue dans ce cas ? ex:

id | libelé | level_id | position-id | parent_id | EN | ES |

1 | Catégorie1 | 1 | 1 | 0 |.......................|.......................| 2 | Catégorie2 | 1 | 2 | 0 |.......................|.......................| 3 | Sous_Catégorie1 | 2 | 1 | 2 |.......................|.......................| 4 | Sous_Catégorie2 | 2 | 2 | 2 |.......................|.......................| 5 | Présentation | 3 | 1 | 4 |.......................|.......................| 6 | Documentation | 3 | 2 | 4 |.......................|.......................| Merci pour vos réponses.

neigedhiver · Accepted Answer

Oui, je comprends ton idée. Mais ça veut dire que dans la même table, le menu est dupliqué pour autant de langues existantes. Les données sont redondantes. C'est pas ce que j'appelle de l'optimisation. Un MCD MERISE n'aboutirait sûrement pas à cette méthode de stockage des données, puisqu'on évite, en général, de stocker une information en double.
On a alors les titre dans chaque langue stockés dans une table séparée, avec une jointure. C'est performant une jointure. Peut-être même plus qu'un WHERE (à bencher pour voir).
Avoir une table séparée n'est vraiment justifié que si on projette d'avoir d'autres langues. Si on n'en a que deux (ou trois, peu importe, un nombre fixe quoi, et qui n'est pas voué à évoluer, JAMAIS) on peut stocker les traductions dans la même table. Ca évite le where et la jointure : c'est encore plus performant, puisqu'on choisit tel ou tel champ suivant la langue (une simple variable php).

Une autre solution est de donner aux items du menu des noms qui seront des clés de traduction (qu'on utilise un tableau, une classe ou autre).
Ca rend la traduction indépendante de la base de données, ça permet d'ajouter autant de langues qu'on veut, ça mange moins de ressources SQL...

yoman64 · Answer

Salut,
moi je ferais une table avec:

id        |        Label            |         ParentID        |     lang
1         |       Categorie1 |                0                    |        EN


2         |       Categorie2 |                0                    |        EN


3         |  Sousmenu1    |               1                    |        EN



4         |   Sousmenu2   |               1                    |        EN



5         |  Soussousmenu1    |               3                    |        EN



6         |   Soussousmenu2   |               3                    |        EN






7         |   Categorie3          |               0                    |        EN







8         |   sousmenu1          |               7                    |        EN

ce qui donnerais un menu du genre:

|
|-->Catégorie 1  |-->Sousmenu1|-->soussousmenu1
|                         |                               |-->Sousousmenu2
|                                 |-->Sousmenu2
|
|--> Catégorie2
|
|-->Catégorie3 |-->Sousmenu1
|

Ou une autre façon de voir:

Catégorie 1
--Sous menu 1
----Sousousmenu 1

----Sousousmenu 2

--Sous menu 2
Catégorie 2
Catégorie 3
--Sousmenu 1

Le parent 0 étant le root.
Mais évidement a la main on s'y perderais vite, donc je te recommenderais de faire un petit script d'admin

-------------------
Vous cherchez un hebergement Php/MySQL Gratuit et sans publicités ?? 
Et bien c'est la : www.e3b.org

Bringdal · Answer

Bonjour,

Ta proposition me va tout à fait mais j'ai encore un petit doute pour le multilingue.
Si je pouvais avoir un autre avis sur la question, ca m'aiderais.

Merci

neigedhiver · Answer

Salut,

J'vais donner mon avis...

J'suis d'accord avec yoman64. Stocker l'id de la catégorie parente est probablement la meilleure solution. Cela permet en outre de construire l'arbre du menu avec une seule requête SQL et une seule boucle, sans récursivité.

Pour la traduction, par contre, deux façons de voir les choses.
Soit tu stockes les traductions dans une table séparée, ce qui te permet de traduire ton menu dans autant de langues que tu le veux, soit tu peux, comme tu le pensais, stocker la traduction dans la même table, à la condition que tu n'aies qu'un nombre bien déterminé de langues.
La première façon de faire permet de rajouter des langues à tout moment très facilement.
La seconde est plus facile à mettre en oeuvre, mais est beaucoup moins souple, puisqu'elle nécessite une modification de la structure de la table pour ajouter une langue. Moins souple, mais plus performante si tu n'as que deux langues. Il te suffit de choisir le nom du champ à récupérer en fonction de la langue.

yoman64 · Answer

Salut,

neigedhivers> Moi je pensais plus a une colonne nomé lang de type ENUM('EN','FR','ES')

Je sais pas si tu me suis, pour construire le menu en français suffis de rajouté un WHERE lang='EN' ou lang='FR' selon la langue! Comme ça on récupère seulement les éléments relatif à la langue, comme si on avait plusieurs tables differentes, mais on gagne encore en performance et en simplicité.

Donc au lieu d'avoir une table par langue tu peux avoir autant de langues que tu veux dans la meme table.

-------------------
Vous cherchez un hebergement Php/MySQL Gratuit et sans publicités ?? 
Et bien c'est la : www.e3b.org

yoman64 · Answer

Ouais tu as raison une jointure j'y avais pas penser. C'est plus propre et peut être plus performant, et surtout, plus facile de s'y retrouvé. 

Pour ce qui est de la performance , comme tu dis, c'est a bencher!

Mais bon si tu n'as que deux langues, utilise simplement deux colonnes.

Je pense donc que mon idée modifié avec les conseils de neigedhiver quant'au multilingue serait la solution la plus approprié.

Sur ce je laisse neigedhiver, ou d'autres, améliorer l'idée si jamais il y a lieu.

-------------------
Vous cherchez un hebergement Php/MySQL Gratuit et sans publicités ?? 
Et bien c'est la : www.e3b.org

Bringdal · Answer

Il est vrai que je doutais sur la duplication de donnée.
Je vais prendre la solution de "neigedhiver"  pour le multilingue.
merci pour le reste des infos "yoman".

Menu Multilingue en base de donnée à 2 ou 3 niveaux

7 réponses

Votre réponse

Discussions similaires