Discussion :

[arnofly]

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 :

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

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.

[Invité]

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 :

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

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

[arnofly]

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

[ABCIWEB]

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.

[Invité]

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.

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 . Il faut que tu utilise une table intermédiaire, c'est à la BDD de traiter les infos pas à ton code métier.

[ABCIWEB]

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 :

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

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

[ABCIWEB]

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

[arnofly]

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.

[ABCIWEB]

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.