Conseil architecture tables fiche produit bilingue

Bonjour tout le monde,

Je commence la réalisation de mon premier site catalogue qui est et devrait rester bilingue. Maintenant que le design est validé par le client, je réfléchis à l'architecture de la base de données et la gestion des langues me pose problème.

La langue française est la langue par défaut du site.
Il est décidé que chaque fiche produit serai consultable en français et en anglais.

La première idée à laquelle j'ai pensé est de créer une colonne pour chaque langue.

Code:

---

1 2 3 4 5 6 7 8 9 10

Table products -------------- id (primary,auto-increment) department_fr department_en title_fr title_en description_fr description_en ...

---

D'après les recherches que j'ai pu effectuer, il semblerait que cette technique soit assez contesté par rapport à l'ajout éventuel de nouvelles langues (le projet sur lequel je travaille n'est pas censé être concerné donc). L'avantage pour moi par contre, c'est que les rèquetes restent simple à formuler. En revanche, j'ai peur que ça fasse un peu table à rallonge.

Une autre technique serait d'utiliser une table spécifique à chaque langue et d'utiliser des jointures (clés étrangères ?). Je n'ai pas trouvé d'exemple concret sur cette architecture et pour le coup j'apprécierais énormément qu'une âme charitable m'explique son fonctionnement plus en détails.

D'avance, merci.

Bonjour, en effet tu pourrais utiliser une table intermédiaire pour stocker tes départements francais, anglais, etc. Tu devrais du coup utiliser des jointures et des clés étrangères (optionnel mais je te conseille).

Par exemple tu aura ceci dans ta table product :
--------------
id (primary,auto-increment)
department_id
title_id
description_id

Et donc une table par exemple department qui contiendrait ceci
--------------
id (primary,auto-increment) correspond au department_id
department_fr
department_en
department_it
...

Pour récupérer la fiche d'une produit tu devras faire cette requête là :

Code:

---

1 2 3

SELECT id, department_fr FROM product, department WHERE product.department_id = department.id

---

C'est vrai que ça serait beaucoup mieux surtout si tu dois ajouter d'autres langues.
Cependant, si tu n'as que deux langues je te conseille de garder ton schéma actuel qui te permettra de faire des requêtes moins complexes et donc moins longues ;)

Table traduction
---------------
id (primary,auto-increment) correspond à l'id produit
lang
department
title
description
---------------

Ce schéma est très recommandé par rapport à ta solution initiale. Beaucoup plus souple et évolutif.

Merci beaucoup pour ta réponse. Je ne suis pas encore très à l'aise avec les bases de données, alors je vais suivre ton conseille et rester sur la première option.

Je profite que tu sois plus rapide que l'éclair pour te poser une autre question ;)

Jusqu'à présent, je n'ai utilisé que des tables "basiques" pour enregistrer une news par exemple. Une fiche produit étant ogligatoirement plus complèxe, comment puis-je enregistrer les caractérisques ? Plus exactement, est-ce que je peux créer une colonne "caractéritiques" et enregister dedans un tableau type (key->value) où les clés seraient le titre d'un libéllé (ex : taille) et la valeur (ex : 105 x 200 mm) ?

C'est pas une bonne idée de rester sur ta première option.

Pour ta deuxième question fais attention quand tu crée des colonnes sans valeur spécifique (donc par exemple si tu enregistre un tableau) car il te sera extrêmement couteux de faire des recherches sur ces colonnes si besoin.

Citation:

---

Envoyé par ABCIWEB

C'est pas une bonne idée de rester sur ta première option.

---

Pourquoi pas si le site reste bilingue ? Ca fera des requêtes plus simples.

Cependant si c'est juste un problème de connaissances et que tu as beaucoup de langues force toi à utiliser la deuxième option.

Citation:

---

Jusqu'à présent, je n'ai utilisé que des tables "basiques" pour enregistrer une news par exemple. Une fiche produit étant ogligatoirement plus complèxe, comment puis-je enregistrer les caractérisques ? Plus exactement, est-ce que je peux créer une colonne "caractéritiques" et enregister dedans un tableau type (key->value) où les clés seraient le titre d'un libéllé (ex : taille) et la valeur (ex : 105 x 200 mm) ?

---

Si tu ne fais pas d'opérations dans les valeurs des caractéristiques pourquoi ne pas tout stocker en texte ?

À l'inverse, si tu souhaites faire des calculs dessus, il faut créer une autre table caractéristiques avec dedans taille, etc...
C'est pas bien de stocker des tableaux en BDD :sm:. Il faut que tu utilise une table intermédiaire, c'est à la BDD de traiter les infos pas à ton code métier.

Au fait pour plus de clarté je précise que j'ai édité mon avant dernier message pour le commentaire du début (un copié/collé que j'avais oublié de modifier pour l'adapter). Dans ce type de table tu pourrais définir un index unique composé des colonnes "id" et "lang".

Re,

C'est clair que je suis un peu low level en MySQL ;) Merci pour vos conseils. Je confirme que je n'ai que 2 langues et que le client ne songe pas à en ajouter d'autres. Après, on ne sais jamais, il peut changer d'avis mais vu la complexité de la traduction (aux dires du futur admin du site), ça semble peu envisageable ;)

Effectivement, l'idée d'enregistrer les caratéristiques d'une fiche produit dans un fichier texte est une bonne idée, car je confirme qu'il n'y aura pas de recherche sur les caractéristiques. Le catalogue conserne des machines très spcifiques dont les caractéristiques donnent mal aux yeux :) Il s'agit d'un site pour du B2B.

Pour donner plus de détails sur le site, il va se présenter sous la forme de plusieurs départements (Forestier, Agricoles, Espaces verts) et dans chaque département, les produits seront regroupés par catégorie/type de produits. Une recherche par nom de produit (pour l'internaute) est amplement suffisante. Le temps qu'il me reste pour faire le code du site me stress un peu.

Encore une question :
J'ai opté pour le moteur MyISAM, mais il me semble avoir lu que l'utilisation des clés étrangères n'était pas gérée par MyISAM. C'est exacte, ou je peux changer de schéma tout en concervant MyISAM ?

Encore merci pour vos interventions.

PS : dans mon précédant message, je répondais à walane. Je ne sais plus trop quoi faire maintenant.

Citation:

---

Envoyé par arnomedia

PS : dans mon précédant message, je répondais à walane. Je ne sais plus trop quoi faire maintenant.

---

:mouarf: Si tu n'es pas très bon en SQL et que le site a juste deux langues prend la première option.

Autrement pour les caractéristiques en effet c'est ce qu'il faut.

Citation:

---

J'ai opté pour le moteur MyISAM, mais il me semble avoir lu que l'utilisation des clés étrangères n'était pas gérée par MyISAM. C'est exacte, ou je peux changer de schéma tout en concervant MyISAM ?

---

Ca par contre c'est pas bien ^^
Passe en InnoDB c'est beaucoup mieux, plus rapide et ça gère les clés étrangères. T'as juste à exécuter cette commande SQL :ccool:

Code:

---

ALTER TABLE ta_table ENGINE = InnoDB;

---

tin, j'ai toujours un train de retard ;)
J'ai édité mon précédant post.

Citation:

---

Envoyé par walane

Ca par contre c'est pas bien ^^
Passe en InnoDB c'est beaucoup mieux, plus rapide et ça gère les clés étrangères.

---

J'ai suivi un tuto qui disait justement le contraire... Donc, plus la discussion avance et plus je recule :) J'utilise quoi alors MyISAM ou InnoDB ?

Citation:

---

Envoyé par walane

Pourquoi pas si le site reste bilingue ? Ca fera des requêtes plus simples.

---

Heu des requêtes plus simples oui mais pas un code plus simple, par exemple avec la première solution, ça fait faire des requêtes distinctes suivant la langue choisie :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

$lang = 'fr'; $id = 12;   if($lang != 'fr') { $query = "SELECT department_en, title_en, description_en   FROM products   WHERE id = $id"; } else { $query = "SELECT department_fr, title_fr, description_fr   FROM products   WHERE id = $id"; }

---

Alors qu'avec une jointure c'est une requête générique valable pour toutes les langues (une, deux ou plusieurs) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$lang = 'fr'; $id = 12;   $query = "SELECT traduction.department, traduction.title, traduction.description   FROM products   LEFT JOIN traduction ON products.id = traduction.id AND traduction.lang = '".$lang."'   WHERE products.id = $id";

---

Bon elle est un peu plus compliquée à écrire mais elle est unique et c'est pas la fin du monde à comprendre et pas besoin de faire des modifs en cas d'ajout de langue.

Donc au final cela te fait moins de code à écrire et au cas où il faudrait rajouter une langue, pas de modif à faire. Sinon imagine un peu le bin's des modifs à faire quand tu auras beaucoup de code. Il te faudra plusieurs jours pour ajouter une autre langue et autant de temps pour la suivante.
C'est pas professionnel et en plus de ton côté tu n'apprends pas les bonnes méthodes. Autant faire des schémas de code qui pourront te resservir.
Tu cumule vraiment tous les désavantages pour une soi-disant facilité qui au final n'en est pas une. De toutes façons si tu veux rester dans ce métier il te faudra apprendre le "minimum" sur les jointures et c'est le moment idéal.

Merci ABCIWEB pour tes exemples. J'adore les exemples ! ;) Je dois dire que tes arguments sont convaincants ;) Loin de moi l'idée de privilégier un code dégueulasse juste pour me faciliter la vie. Je vais donc essayer de suivre ton conseil et bucher les jointures.

Pour l'enregistrement des caractéristiques d'un produit, quelle méthode emploierais-tu stp ? Concernant les images de chaque produit, j'ai choisi de les stocker dans un répertoire dont le nom correspondra à celui de l'ID d'un produit. Pour les caractéristiques, je fais pareil, je les enregistre directement dans un fichier HTML stocké dans le même répertoire que les images ?

Code:

---

1 2 3 4 5 6 7 8 9 10

-12 --- specs_fr.html --- specs_en.html --- img_1.jpg --- img_2.jpg --- img_3.jpg   -13 ...

---

Encore merci

Tu as une base de données profites-en, pourquoi stocker les caractéristiques dans un fichier html, tu as déjà vu des exemples dans ce sens ? Il me semble que walane parlait d'un champ texte de ta bdd, pas d'un fichier texte séparé.

Et on ne fait rien correspondre à l'id sauf éventuellement une clé dans une autre table, mais normalement l'identificateur d'une table produit devrait être par exemple le code produit et pas un id auto incrémenté qui ne devrait être choisi que comme dernière solution pour identifier une ligne. Donc pour ton image, pourquoi ne pas stocker le nom de ton image (ou le chemin plus complet avec le nom du dossier) dans un champ de ta table ? Et si plusieurs images possibles, une table image et une jointure.

En effet il faut stocker les caractéristiques dans la BDD. Tout ce qui persiste et modifiable doit être en BDD, surtout pas dans des fichiers html.

Pour l'image, à toi de voir quel champ tu veux utiliser mais il faut qu'il soit unique pour distinguer l'image. D'autre part je te conseille de stocker uniquement le nom de l'image mais pas le chemin complet. En effet si tu dois changer de serveur tu seras bien content de ne pas toucher à ta BDD.

Stocke l'image comme ceci : "418.png" et avec PHP tu récupères le chemin complet : $_SERVER['DOCUMENT_ROOT_OU_JE_SAIS_PLUS_TROP_QUOI'] . $image; :ccool:

Et as-tu changer pour INNODB ?

Slt ;)

En fait, je viens de créer une base test en InnoDB pour pouvoir m'entrainer avec les jointures.

Donc, si j'ai bien compris cette fois, j'enregistre dans la colonne des caractéristiques mon texte déja formaté en html.
NB : Exemple d'un enregistrement d'une liste:

Code:

---

<ul><li>Titre item 1 : description item 1</li><li>Titre item 2 : description item 2</li><li>Titre item 3 : description item 3</li></ul>

---