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

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

[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]

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.

[Invité]

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

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.

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

Code :

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

ALTER TABLE ta_table ENGINE = InnoDB;

[arnofly]

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

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 ?

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

[arnofly]

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 :

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

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

[ABCIWEB]

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.

[Invité]

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;

Et as-tu changer pour INNODB ?

[arnofly]

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 :

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

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