Discussion :

[redah75]

Bonjour,
j'espere que je poste au bon endroit!

j'aurais 3 petites questions:

je suis entrain de reflechir a concevoir un site ecommerce multilingues, une decision quant a la maniere de le faire a ete price a l'issu de ce topic (fichiers de traductions xml): http://www.developpez.net/forums/d80...multi-langues/
mais les questions que je me pose maintenant sont:

1- je vais avoir themes -> rubriques -> produits
le menu sera construit a partir du contenu de themes, rubriques et produits.
les petits exemples avec lesquels je travaillaient ne sont plus valable car ce que je veux faire mnt est un peu costaud. j'ai mis dans un fichier .php la stucture du menu manuellement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$menu = array(
		'rubrique1' => array( // element id => sous menu
			'cat1',
			'cat2',
			'cat3',
			'cat4'
		),
		'rubrique2' => array(
			'cat5',
			'cat6',
			'cat7'
		),
		...
);

rubrique1, cat1, cat2 sont des variable qui figurent dans le fichier de traduction...
je me rends compte que rubrique1, rubrique2, cat1, cat2, ... seront mieux placés dans une base de données, car si une nouvelle rubrique s'ajoute, je serai obligé de la rajouté a la main dans ce fichier text. Approuvez vous ce choix ??

2- rubrique1, rubrique2, cat1, cat2, ... seront dans une table de "references": rubriques (id_rub, libelle) mais sachant que les libellés vont etre en plusieurs langues, comment pourrais je concevoir cette table? je vois un truc du genre: rubriques (id_rub, id_trad, lang, libelle):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
1   1   en   Hello
2   2   en   Good
2   3   fr   Bien
2   4   es   Bueno
1   5   fr   Bonjour

mais je suis sur qu'il doit y avoir plus simple, je suis a cours d'idees

3- et une derniere question, quelle est la meilleure structure pour une table qui stocke des "chaussures" sachant que le meme model peut exister en plusieurs couleur, model, et pointures...

Merci infiniment
Reda

[RunCodePhp]

mais je suis sur qu'il doit y avoir plus simple

Plus simple, je n'en sais rien, mais pour ce qui est de stocker les infos comme "rubrique", "categories" etc ... une base de données me semble indispensable, je ne vois pas comment on pourrait faire sans.

Ton site proposera obligatoirement de faire des recherches, que ce soit dans les rubriques, catégories, produits, etc ... avec même plusieurs critères (sur le nom des produits, des catégories, le prix, et surtout sur le contenu linguistique des produits, etc ...)
Si tous ces contenus, voir même 1 seul se trouve dans du XML et les autres dans la Bdd, (ou pire, du tout XML), il te seras impossible, du moins très compliqué (hyper même) de faire des jointures, de mettre tout ceci en relation pour ressortir très exactement des produits par exemple.


A mon sens, les seuls éléments qui pourraient être placés dans des fichiers XML, c'est les contenu propre à l'interface, totalement éloignés du contenu des produits, catégories, rubrique etc ...

Aussi, j'ai jamais vraiment adhéré d'utiliser des noms comme clés primaire, mais plutôt des IDs, comme pour la langue.
J'aurais donc créé une table "langue" avec au moins 2 champs :
lang_id, code
1, fr
2, en
etc ...

De plus, le fait d'avoir une table "langue", tu pourrais l'exploiter pour renseigner le nom où ce trouverait le fichier linguistique, ou le nom du répertoire pour peu qu'il y aurait plusieurs type de contenu linguistique (ça risque fort d'être le cas).
Voir d'autres infos propres à chaque langue.
Tout ceci permettra de rendre l'application plus dynamique, plus automatisée.
lang_id, code, rep
1, fr, francais
2, en, anglais
etc ...

Pour ce qui est de la rubrique, là aussi j'aurais fais autrement, séparé les relations propres entre rubrique|categories et les contenu linguistiques (en se basant sur la table "langue")
table categories
cat_id, statut, date_cree (le statut pour : valide ou non valide, donc 0 ou 1)
1, 1, 2010-04-10
2, 0, 2010-04-10
3, 1, , 2010-04-10
etc ...
table categories_lang
cat_id, lang_id, nom, date_creation
1, 1, cat_un
1, 2, cat_one
2, 1, cat_deux
2, 2, cat_two
etc ...

table rubrique
rubrique_id, statut, date_cree
1, 1, 2010-04-10
2, 0, 2010-04-10
3, 1, 2010-04-10
etc ...
table rubrique_lang
rubrique_id, lang_id, nom
1, 1, rub_un
1, 2, rub_one
2, 1, rub_deux
2, 2, rub_two
etc ...

rubrique_et_categories
rubrique_id, cat_id
1, 1
1, 2
1, 3
1, 4
2, 5
2, 6
2, 7


Comme tu peux voir, ce modèle est plus compliqué (malheureusement), car il y a plus de tables, tout est doublé, du moins, les données propres séparées du contenu linguistique, mais c'est théoriquement comme ceci que la Bdd devrait être conçue. (je dis bien théoriquement).
A l'usage, pour récupérer les contenus, tout est une question de jointure.

Tu remarqueras d'ailleurs que j'ai rajouté par endroit 2 champs : un statut et une date de création.
Ceci est évidemment volontaire pour mieux te rendre compte que, si tu souhaite avoir ce genre d'infos, et bien si on ne sépare pas les choses, il va avoir un phénomène de répétition sur certaines données.
A titre d'exemple, et théoriquement, si on décide de ne pas proposer/afficher une catégorie (pour X ou Y raison), il n'y a pas lieu de répéter cette info pour chaque langue (le statut).
Même chose pour la date de création de la catégorie par exemple.


Tout ceci est juste pour information, il est évident que tu est le seul à savoir si cela correspond ou pas à se que tu souhaite faire.

[redah75]

Bonjour et Merci RunCodePhp pour ta reponse bien detailee!

Aussi, j'ai jamais vraiment adhéré d'utiliser des noms comme clés primaire, mais plutôt des IDs, comme pour la langue.
J'aurais donc créé une table "langue" avec au moins 2 champs :
lang_id, code
1, fr
2, en
etc ...

je sais mais dans ces exemple, j'utilise fr et en juste pour simplifier les choses

cat_id, statut, date_cree (le statut pour : valide ou non valide, donc 0 ou 1)
1, 1, 2010-04-10
2, 0, 2010-04-10
3, 1, , 2010-04-10
etc ...
table categories_lang
cat_id, lang_id, nom, date_creation
1, 1, cat_un
1, 2, cat_one
2, 1, cat_deux
2, 2, cat_two
etc ...

c'est bien ce que j'avais en tete, sans le champs valide et date mais ca me paraissait un peu bizarre d'avoir une table avec un seul champ!!
du coup, voila ce que je vais faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
table menu (id_menu, id_cat, valid, dt) : // melange de themes, rubriques et categories, j'utilise 'y' et 'n' pour les champs boolean
1    1    y     2009-04-29
2    1    y     2009-04-29
3    2    y     2009-04-29
4    2    y     2009-04-29
5    2    y     2009-04-29
...
 
table menu_traductions (id_menu, lang, libelle) :
1    fr    Bonjour
1    es    Hola
1    en    Hello
2    fr    Bonne nuit
2    en    Good night
...
 
table categories (id_cat, libelle) :
1    Theme
2    Rubrique
3    Categorie
...

j'ai par contre du mal a voir comment creer la table qui permettra de constituer le menu qui est de 3 niveaux :
"Theme 1" contiendra "Rubrique 1" qui contiendra "categorie 1", "categorie 2", "categorie 3", ...

oh lalaaaa, une vrai prise de tete!!

[RunCodePhp]

j'ai par contre du mal a voir comment creer la table qui permettra de constituer le menu qui est de 3 niveaux :
"Theme 1" contiendra "Rubrique 1" qui contiendra "categorie 1", "categorie 2", "categorie 3"

Tu parle de rubrique, mais on pourrait aussi "niveau" ou "arborescence".
En faite, c'est ni plus ni moins comme sur PC, un répertoire qui contiendrait d'autres répertoires, et ces derniers, des fichiers.
Mais le terme "rubrique" reste correcte. C'est juste pour se le représenter différemment.

Il me semble avoir donner un bon exemple (pas très bien présenté peut être).
Il faut 3 tables, il me semble difficile d'en faire moins (comme vouloir le faire avec 2 tables seulement).
Je ne sait pas si je parviendrais à le formuler autrement (j'suis pas prof, que veux tu).

Il faudrait une première table, qui elle se contenterait de contenir les différentes rubriques.
Table "rubriques"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
ID  | valid
----------
1   | y
2   | y
3   | n

La même, mais cette fois pour la séparation donnée/langue.
Table "rubriques_traduction"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
ID  | lang | libelle
-----------------
1   | en   | rub_1_EN
1   | fr   |  rub_1_FR
2   | en   | rub_2_EN
2   | fr   | rub_2_FR
3   | en   | rub_3_EN
3   | fr   | rub_3_FR

(sorry pour les noms bidons, et pas très top ... m'enfin, on fait c'qu'on peu)
Les champs ID et lang devront être tous 2 la clé primaire, donc une clé double.
Exemple : PRIMARY KEY (ID, lang)
(Faudra faire de même pour la table "menu_traductions")
Maintenant, on a les rubriques. C'est comme pour les menus, il y a rien de plus.

Reste une table pour lier chaque menu à aux rubriques (ou inversement).
Table "rubriques_menu"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
id_rub | id_menu
-----------------
1      | 1
1      | 2
1      | 3
1      | 4
2      | 5
2      | 6
2      | 7

Là aussi il faudra créer une clé double.
PRIMARY KEY (id_rub, id_menu)

j'ai par contre du mal a voir comment creer la table qui permettra de constituer le menu qui est de 3 niveaux

Tu est sûr qu'il y a 3 niveau ?
J'en vois que 2 : 1 Rubrique (niveau 1) contient une séries de menus (niveau 2).
Peut importe le nombre de rubriques (1 ou 10), et peu importe ne nombre de menus.

[redah75]

Tu est sûr qu'il y a 3 niveau ?
J'en vois que 2 : 1 Rubrique (niveau 1) contient une séries de menus (niveau 2).
Peut importe le nombre de rubriques (1 ou 10), et peu importe ne nombre de menus.

Oui, j'en ai 3 et ca peut devenir 4 a l'avenir...
Pour parler de choses plus concretes, voici a peu pres a quoi resemblera mon menu
Maison, Soin & Beauté, ... (niveau 1)
quand on clique sur "Maison" on trouve:
Salle de bain, Salle a manger, Cuisine, ... (niveau 2)
et quand on clique sur "Salle a manger" on trouve:
Tables, Chaises, Plateaux, Accessoires, ... (niveau 3)
c'est un peu comme le site de ikea.fr

Reste une table pour lier chaque menu à aux rubriques (ou inversement).
Table "rubriques_menu"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
id_rub | id_menu
-----------------
1      | 1
1      | 2
1      | 3
1      | 4
2      | 5
2      | 6
2      | 7

j'ai un peu de mal a te suivre, dans ton exemple, quelle sera la table menu?
moi je compte regrouper les elements du menu, rubriques et categories dans la meme table et les differencier par un champ comme je l'ai montre dans la table "menu"

[RunCodePhp]

Oui, j'en ai 3 et ca peut devenir 4 a l'avenir...
Pour parler de choses plus concretes, voici a peu pres a quoi resemblera mon menu
Maison, Soin & Beauté, ... (niveau 1)
quand on clique sur "Maison" on trouve:
Salle de bain, Salle a manger, Cuisine, ... (niveau 2)
et quand on clique sur "Salle a manger" on trouve:
Tables, Chaises, Plateaux, Accessoires, ... (niveau 3)

Ca change pas mal les choses.
A aucun moment, ni aucun de tes exemples n'ont représentés ça.


Ca se peut qu'il existe plusieurs moyens de le faire, mais le problème, c'est que j'utilise qu'1 seule technique, et ça depuis pas mal de temps.
Du coup, je me suis pas vraiment penché sur le comment faire autrement.

Je vais te le décrire, mais attention, ce n'est pas dit que c'est la meilleure façon de faire.
D'ailleurs, et théoriquement, ça ne respecte pas les bonnes conventions de conceptions d'une Bdd, il "casse" un peu les règles.
L'avantage, c'est qu'il est simple à mettre en oeuvre coté Bdd (c'est surement pour cette raison que certain l'adopte).
Cependant, il a un inconvénient du coté du code Php, ça demandera de faire des trucs particuliers.
A voir donc ...


Le truc ici, serait de ne plus faire allusion à des rubriques, mais avoir qu'une table categories (enfin, 2 pour les langues), et la particularité c'est que des catégories contiennent d'autres catégories.
Pour représenter ça, il y a 2 champs : cat_id, parent_id
Du coup, on peu avoir une arborescence infinie, un nombre de niveau infini.
Ce n'est pas pour autant qu'il faudra créer 10 ou 15 niveau, sinon ça devient un vrai labyrinthe.
C'est donc soit même qui décide le nombre de niveau, ou d'imbrication.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Table categories
cat_id | parent_id | valid
--------------------------
1      | 0      | y
2      | 0      | y
3      | 1      | y
4      | 1      | n
5      | 4      | y
6      | 4      | y
7      | 4      | y
8      | 7      | y
9      | 7      | y
10     | 2     | y

Ici, j'ai représenté 4 niveaux.
Le 1er ce sont les catégories enfants 1,2 dont la catégorie parente vaut 0
Le 2ème ce sont les cat. enf. 3,4 dont la cat. parente vaut 1
Le 3ème les cat. enf. 5,6,7 dont la cat. parent vaut 4 (celle ci dessus)
Le 4ème les cat. enf. 8,9 dont la cat. parent vaut 7 (celle ci dessu aussi)
Ce qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
c(1) - p(0) [NIVEAU 1]
--------- c(3) - p(1) [NIVEAU 2]
 
--------- c(4) - p(1) [NIVEAU 2]
------------------c(5) - p(4) [NIVEAU 3]
 
------------------ c(6) - p(4) [NIVEAU 3]
 
------------------ c(7) - p(4) [NIVEAU 3]
--------------------------- c(8) - p(7) [NIVEAU 4]
--------------------------- c(8) - p(7) [NIVEAU 4]
 
c(2) - p(0)
--------- c(10) - p(2) [NIVEAU 2]

Ici, j'ai rien fais coté langue/libellés, mais faudra une table pour ça, comme vu dans les post plus hauts.

En espérant de ne pas m'être trompé non plus.

Après, il faudra une table produits (ou articles, ou autre éléments, peu importe le nom) qui sera lié à tout ça, une table qui contiendra que 2 champs (cat_id, article_id), une d'un nom du genre categories2articles (indépendamment de la table articles).


Si ceci ne correspond pas à tes attentes, faudrait peut être voir du coté des Softs, genre Open Source, et voir quelles technique il utilise.