Discussion :

[aras-vbo]

Bonjour,

Le projet consiste à modéliser le site d'un fabricant de matériel.

Par commodité, le projet a été découpé en plusieurs étapes, ajoutant des sections (avec leurs fonctionnalités spécifiques) à chaque itération. Le découpage est le suivant :
1 - réalisation de la section catalogue des produits
2 - réalisation de la section listant les revendeurs du matériel produit par le fabricant
3 - réalisation de la section de support technique, incluant les modes d'emploi, des how-tos, etc.

Il n'est pas prévu de système de commande en ligne mais, si la modélisation est suffisamment modulaire, il ne devrait pas être compliqué de l'ajouter par la suite.


Modélisation du catalogue des produits

J'ai essayé de suivre la méthodologie classique proposée par les membres aguerris du forum et par Patrick Bergougnoux (@Paprick) dans son livre. Les modèles ont été réalisés avec Looping.


1 - Dictionnaire des données

Suite à une analyse du système à modéliser, j'ai tenté de lister les différentes rubriques à insérer dans le modèle. Paprick suggère, dans son livre, d'analyser les flux d'information pour en extraire les rubriques. Dans mon cas, ce n'est pas très facile car il n'y a pas de flux à proprement parlé, juste des entités. J'ai donc listé les entités et extrait les rubriques.

Voici le tableau que j'obtiens

n°	Libellé	Primaire/Calculable
1	Nom du produit	P
2	Référence du produit	P
3	Date de mise sur le marché du produit	P
4	Date de retrait du marché du produit	P
5	Image du produit	P
6	Descriptif du produit	P
7	Nom du fabricant du produit	P
8	Nom de la gamme de produits	P
9	Image de la gamme de produits	P
10	Descriptif de la gamme de produits	P
11	Nom de la catégorie	P
12	Image de la catégorie	P
13	Descriptif de la catégorie	P
14	Contenu du produit	P

Je n'ai pas considéré la rubrique 7 (Nom du fabricant du produit) comme un paramètre car, dans l'étape 3 du projet, il est prévu de mettre en place un système permettant de lister et d'expliquer le montage d'accessoires d'autres marques sur le matériel du fabricant. Par conséquent, j'ai préféré anticiper pour ne pas avoir à modifier le modèle à l'étape 3.

De ce tableau découlent les entités suivantes :
- Marque
- Produit
- Gamme
- Catégorie

Je n'ai pas rédigé de glossaire car les termes utilisés dans ce projet sont triviaux (catégorie, produit, gamme de produits, etc.).


2 - Règles de gestion

Voici les règles de gestion qui s'appliquent au système modélisé.

Marque :
RM01 : Une marque fabrique au moins un produit
RM02 : Un produit n'appartient qu'à une seule marque

Produit :
RP01 : Un produit peut posséder la même référence qu'un autre
RP02 : Un produit possède une date de mise sur le marché et une date de retrait du marché
RP03 : Le nom d'un produit peut être traduit dans une ou plusieurs langues
RP04 : Pour chaque langue, le produit porte un seul nom.
RP05 : Un produit peut contenir zéro, un ou plusieurs autres produits.
RP06 : Le contenu d'un produit est d'un seul type* : pack, contenu ou accessoire.
RP07 : Un produit est décrit par zéro, un ou plusieurs descriptifs de produit (descriptif complet, résumé, etc.)
RP08 : Un descriptif de produit décrit un seul produit
RP09 : Un descriptif de produit peut être traduit dans plusieurs langues
RP10 : Un produit est représenté par une ou plusieurs images
RP11 : Chaque produit possède une image par défaut

Gamme :
RG01 : Une gamme contient au moins un produit
RG02 : Un produit appartient à zéro, une ou plusieurs gammes
RG03 : Pour chaque langue, la gamme porte un seul nom
RG04 : Une gamme est décrite par zéro, un ou plusieurs descriptifs de gamme (descriptif complet, résumé, etc.)
RG05 : Un descriptif de gamme décrit une seule gamme
RG06 : Un descriptif de gamme peut être traduit dans une ou plusieurs langues
RG07 : Une gamme est représentée par une ou plusieurs images
RG08 : Chaque gamme possède une image par défaut

Catégorie :
RC01 : Une catégorie possède zéro, un ou plusieurs produits
RC02 : Une catégorie possède zéro, une ou plusieurs catégories filles
RC03 : Une catégorie possède une ou plusieurs catégories parentes
RC04 : Le nom d'une catégorie peut être traduit dans une ou plusieurs langues
RC05 : Pour chaque langue, la catégorie porte un seul nom
RC06 : Une catégorie est décrite par zéro, un ou plusieurs descriptifs de catégorie (descriptif complet, résumé, etc.)
RC07 : Un descriptif de catégorie décrit une seule catégorie
RC08 : Un descriptif de catégorie peut être traduit dans une ou plusieurs langues
RC09 : Une catégorie est représentée par une seule image

* Précisions sur les types de contenu d'un produit :
- Un pack est un groupe de produits qui sont proposés ensemble de façon occasionnelle. Il est possible de séparer les éléments du pack sans ouvrir le carton d'emballage.
- Un contenu est l'ensemble des produits individuels qui sont inclus dans le carton d'emballage du produit parent mais qui ne sont pas montés sur le produit parent. Il est possible de séparer les éléments du contenu uniquement en ouvrant le carton.
- Un accessoire est un produit individuel inclus dans le carton d'emballage et monté sur le produit parent. Il n'est possible de retirer un accessoire qu'en ouvrant le carton et en démontant le produit parent.


3 - Modèle Conceptuel des Données

Suite à plusieurs discussions avec fsmrel sur les approches de modélisation des catégories (arbre hiérarchique) et d'internationalisation des noms et des descriptifs, j'obtiens le MCD suivant, réalisé sous Looping :



- Le slug est un champ "technique" contenant l'URL unique et explicite utilisé pour le référencement naturel par les moteurs de recherche. Il n'est utilisé que pour les liens vers les pages de catégorie, de gamme et de produit. Le slug est généré automatiquement à partir du nom dans la langue concernée ; tee-shirt bleu à manches longues devient tee-shirt-bleu-a-manches-longues, par exemple.
- Les champs booléens supplémentaires (est_actif, est_affiche) sont destinés à masquer rapidement et facilement les entités dans le site. Ils permettront d'éditer le contenu en toute sécurité avant publication.
- Les champs est_special et est_produit de Categorie sont destinés aux menus et aux règles d'affichage du contenu des catégories. Il m'a paru plus judicieux d'intégrer ce type de flag dans la base plutôt que de rédiger du code tarabiscoté chargé de gérer les exceptions de formatage.
- Le type dans la relation contenir reliant les produits à eux-mêmes sera géré par une énumération.

Voici le code SQL généré par Looping :

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
CREATE TABLE catalogue_langue(
   id_langue COUNTER,
   nom_langue VARCHAR(100) NOT NULL,
   code_langue_iso2 VARCHAR(2) NOT NULL,
   code_langue_iso3 VARCHAR(3) NOT NULL,
   est_actif LOGICAL NOT NULL DEFAULT=false,
   est_affiche LOGICAL NOT NULL DEFAULT=false,
   PRIMARY KEY(id_langue)
);

CREATE TABLE catalogue_marque(
   id_marque COUNTER,
   nom VARCHAR(100) NOT NULL,
   est_active LOGICAL NOT NULL DEFAULT=false,
   est_affichee LOGICAL NOT NULL DEFAULT=false,
   PRIMARY KEY(id_marque),
   UNIQUE(nom)
);

CREATE TABLE catalogue_produit(
   id_produit COUNTER,
   reference VARCHAR(16) NOT NULL,
   date_creation DATETIME NOT NULL,
   date_disparition DATETIME,
   est_actif LOGICAL NOT NULL DEFAULT=false,
   est_affiche LOGICAL NOT NULL DEFAULT=false,
   id_marque INT NOT NULL,
   PRIMARY KEY(id_produit),
   FOREIGN KEY(id_marque) REFERENCES catalogue_marque(id_marque)
);

CREATE TABLE catalogue_categorie(
   id_categorie VARCHAR(50),
   est_actif LOGICAL NOT NULL DEFAULT=false,
   est_affiche LOGICAL NOT NULL DEFAULT=false,
   est_special LOGICAL NOT NULL DEFAULT=false,
   est_produit LOGICAL NOT NULL DEFAULT=false,
   PRIMARY KEY(id_categorie)
);

CREATE TABLE catalogue_gamme(
   id_gamme COUNTER,
   est_actif LOGICAL NOT NULL DEFAULT=false,
   est_affiche LOGICAL NOT NULL DEFAULT=false,
   PRIMARY KEY(id_gamme)
);

CREATE TABLE catalogue_nom(
   id_nom COUNTER,
   nom VARCHAR(150) NOT NULL,
   slug VARCHAR(150) NOT NULL,
   id_langue INT NOT NULL,
   PRIMARY KEY(id_nom),
   UNIQUE(slug),
   FOREIGN KEY(id_langue) REFERENCES catalogue_langue(id_langue)
);

CREATE TABLE catalogue_descriptif(
   id_descriptif COUNTER,
   descriptif TEXT NOT NULL,
   derniere_modification DATETIME NOT NULL DEFAULT = now(),
   est_active LOGICAL NOT NULL DEFAULT=false,
   est_affichee LOGICAL NOT NULL DEFAULT = now(),
   id_langue INT NOT NULL,
   PRIMARY KEY(id_descriptif),
   FOREIGN KEY(id_langue) REFERENCES catalogue_langue(id_langue)
);

CREATE TABLE catalogue_image(
   id_image COUNTER,
   nom_image VARCHAR(150) NOT NULL,
   est_active LOGICAL NOT NULL DEFAULT=false,
   est_affichee LOGICAL NOT NULL DEFAULT=false,
   PRIMARY KEY(id_image)
);

CREATE TABLE catalogue_contenu_categorie(
   id_categorie_EnfantId VARCHAR(50),
   id_categorie_ParentId VARCHAR(50) NOT NULL,
   PRIMARY KEY(id_categorie_EnfantId),
   FOREIGN KEY(id_categorie_EnfantId) REFERENCES catalogue_categorie(id_categorie),
   FOREIGN KEY(id_categorie_ParentId) REFERENCES catalogue_categorie(id_categorie)
);

CREATE TABLE catalogue_contenu_produit(
   id_produit_ItemId INT,
   type VARCHAR(50) NOT NULL,
   id_produit INT NOT NULL,
   PRIMARY KEY(id_produit_ItemId),
   FOREIGN KEY(id_produit_ItemId) REFERENCES catalogue_produit(id_produit),
   FOREIGN KEY(id_produit) REFERENCES catalogue_produit(id_produit)
);

CREATE TABLE catalogue_gamme_produit(
   id_gamme INT,
   id_produit INT,
   PRIMARY KEY(id_gamme, id_produit),
   FOREIGN KEY(id_gamme) REFERENCES catalogue_gamme(id_gamme),
   FOREIGN KEY(id_produit) REFERENCES catalogue_produit(id_produit)
);

CREATE TABLE catalogue_categorie_produit(
   id_produit INT,
   id_categorie VARCHAR(50),
   PRIMARY KEY(id_produit, id_categorie),
   FOREIGN KEY(id_produit) REFERENCES catalogue_produit(id_produit),
   FOREIGN KEY(id_categorie) REFERENCES catalogue_categorie(id_categorie)
);

CREATE TABLE catalogue_nom_produit(
   id_produit INT,
   id_nom INT,
   PRIMARY KEY(id_produit, id_nom),
   FOREIGN KEY(id_produit) REFERENCES catalogue_produit(id_produit),
   FOREIGN KEY(id_nom) REFERENCES catalogue_nom(id_nom)
);

CREATE TABLE catalogue_nom_gamme(
   id_gamme INT,
   id_nom INT,
   PRIMARY KEY(id_gamme, id_nom),
   FOREIGN KEY(id_gamme) REFERENCES catalogue_gamme(id_gamme),
   FOREIGN KEY(id_nom) REFERENCES catalogue_nom(id_nom)
);

CREATE TABLE catalogue_nom_categorie(
   id_categorie VARCHAR(50),
   id_nom INT,
   PRIMARY KEY(id_categorie, id_nom),
   FOREIGN KEY(id_categorie) REFERENCES catalogue_categorie(id_categorie),
   FOREIGN KEY(id_nom) REFERENCES catalogue_nom(id_nom)
);

CREATE TABLE catalogue_description_categorie(
   id_categorie VARCHAR(50),
   id_descriptif INT,
   PRIMARY KEY(id_categorie, id_descriptif),
   FOREIGN KEY(id_categorie) REFERENCES catalogue_categorie(id_categorie),
   FOREIGN KEY(id_descriptif) REFERENCES catalogue_descriptif(id_descriptif)
);

CREATE TABLE catalogue_description_produit(
   id_produit INT,
   id_descriptif INT,
   PRIMARY KEY(id_produit, id_descriptif),
   FOREIGN KEY(id_produit) REFERENCES catalogue_produit(id_produit),
   FOREIGN KEY(id_descriptif) REFERENCES catalogue_descriptif(id_descriptif)
);

CREATE TABLE catalogue_description_gamme(
   id_gamme INT,
   id_descriptif INT,
   PRIMARY KEY(id_gamme, id_descriptif),
   FOREIGN KEY(id_gamme) REFERENCES catalogue_gamme(id_gamme),
   FOREIGN KEY(id_descriptif) REFERENCES catalogue_descriptif(id_descriptif)
);

CREATE TABLE catalogue_image_categorie(
   id_categorie VARCHAR(50),
   id_image INT,
   PRIMARY KEY(id_categorie, id_image),
   FOREIGN KEY(id_categorie) REFERENCES catalogue_categorie(id_categorie),
   FOREIGN KEY(id_image) REFERENCES catalogue_image(id_image)
);

CREATE TABLE catalogue_image_produit(
   id_produit INT,
   id_image INT,
   par_defaut LOGICAL NOT NULL,
   PRIMARY KEY(id_produit, id_image),
   FOREIGN KEY(id_produit) REFERENCES catalogue_produit(id_produit),
   FOREIGN KEY(id_image) REFERENCES catalogue_image(id_image)
);

CREATE TABLE catalogue_image_gamme(
   id_gamme INT,
   id_image INT,
   par_defaut LOGICAL NOT NULL,
   PRIMARY KEY(id_gamme, id_image),
   FOREIGN KEY(id_gamme) REFERENCES catalogue_gamme(id_gamme),
   FOREIGN KEY(id_image) REFERENCES catalogue_image(id_image)
);

CREATE TABLE catalogue_image_description(
   id_descriptif INT,
   id_image INT,
   PRIMARY KEY(id_descriptif, id_image),
   FOREIGN KEY(id_descriptif) REFERENCES catalogue_descriptif(id_descriptif),
   FOREIGN KEY(id_image) REFERENCES catalogue_image(id_image)
);

Avant d'avancer dans les autres scripts de la base de données (vues, procédures stockées ou déclencheurs) ou d'envisager d'optimiser le MPD, je souhaiterai savoir si mon MCD vous paraît pertinent.

Merci par avance,
Vincent

[escartefigue]

Bonjour Vincent,

Le décor est planté, le contexte décrit et les règles de gestion fournies, bravo

Pour les règles de gestion, il est plus simple d'utiliser le même verbe dans les deux sens des associations et dans le MCD

par exemple
RG01 : une gamme contient au moins un produit
RG02 : un produit appartient à zéro, une ou plusieurs gammes

devient
RG01 : une gamme contient au moins un produit
RG02 : un produit est contenu dans zéro, une ou plusieurs gammes

Et dans le MCD, on appellera l'association correspondante "contenir"


Au niveau du vocabulaire, plutôt que des "champs", on parlera d'attributs au niveau conceptuel, puis de colonnes au niveau tabulaire.
Les "champs" sont des zones de saisie des formulaires et les zones d'édition d'un état, sans rapport avec la modélisation des données .


Concernant les produits
Je n'ai pas compris comment interpréter RP05, s'agit il d'une notion de composant/composé ?
Si c'est le cas, la relation réflexive devrait sans doute être 0,n de chaque coté : un composant peut entrer dans la composition de plusieurs produits et un produit peut être composé de plusieurs composants.

Je suis surtout surpris par la règle RP01 : que plusieurs fabricants ou fournisseurs aient la même référence, pourquoi pas, le hasard peut faire que, mais en interne, n'y a -t-il pas une référence produit qui, elle, devrait être unique ?
En d'autres termes, il faut distinguer la référence fournisseur, unique pour un fournisseur, mais potentiellement en doublons sur l'ensemble des fournisseurs, de la référence interne qui d'expérience est toujours unique.


Concernant la gestion multilingue je verrai plutôt une modélisation comme suit (ici pour le cas du nom du produit) :



Ainsi le libellé dans telle ou telle langue est un attribut de l'association entre la langue et l'objet de gestion considéré (le produit, la catégorie, la gamme...) et l'entité-type [NOM] disparait. En effet, celle-ci n'aurait d'intérêt que dans le cas où un même nom désignerait à la fois un produit, une catégorie, une gamme... et qu'en cas de changement, celui-ci s'applique partout, ce qui me semble peu probable.


D'autres questions viendront sans doute plus tard

[fsmrel]

Salve omnes,

Je n'ai pas compris comment interpréter RP05, s'agit il d'une notion de composant/composé ?

Il s’agit d’un arbre hiérarchique. Paprick et moi-même avons traité avec aras-vbo de cette affaire, cf. la discussion Modélisation d'un arbre hiérarchique.

Concernant la gestion multilingue

Le problème des slugs a été traité dans la discussion Internationalisation des données (i18n).


Je ne suis pas très réactif, mais j’essaie pour le moment de me remettre de deux interventions chirurgicales. Les salles d’attente sont les lieux où j'ai l’occasion de réfléchir aux solutions aux problèmes posés chez developpez.com...

[escartefigue]

Merci François pour les liens et surtout bon rétablissement !

@Vincent : après consultation du lien sur l'internationalisation, j'ai tout de même du mal à imaginer que le libellé d'une catégorie puisse aussi être celui d'un produit et d'une gamme (sauf de façon exceptionnelle), d'où ma proposition de suppression de l'entité-type [NOM].
Quelques exemples de contenus seraient les bienvenus.

[fsmrel]

j'ai tout de même du mal à imaginer que le libellé d'une catégorie puisse aussi être celui d'un produit et d'une gamme

Selon Vincent, la collision des noms est possible, notamment en ce qui concerne les slugs et c’est un souci. Vincent anticipe et s’équipe de ceintures, bretelles et épingles à nourrice, on ne saurait lui en vouloir. De sa part il y a de la prudence, de la sagesse derrière tout ça. Dans l’esprit, l’entité-type NOM relève de la globalisation, ce qui est tout à fait respectable. Techniquement parlant il n’y a aucun problème, et la partie du MCD que tu proposes revient à la mise en oeuvre d’une vue au stade SQL. Qui peut le plus peut le moins. Et puis : Better prevent than cure...

[aras-vbo]

Bonjour à vous,

Tout d'abord, je souhaite moi aussi un bon rétablissement à François. Revenez-nous rapidement et en pleine forme !

Suite aux remarques d'escartefigue, j'ai réécrit mes règles de gestion :

Marque :
RM01 : Une marque fabrique au moins un produit
RM02 : Un produit n'est fabriqué que par une seule marque

Produit :
RP01 : Un produit peut posséder la même référence qu'un autre
RP02 : Un produit possède une date de mise sur le marché et une date de retrait du marché
RP03 : Le nom d'un produit est traduit dans une ou plusieurs langues
RP04 : Pour chaque langue, le produit porte un seul nom.
RP05 : Un produit contient zéro, un ou plusieurs autres produits.
RP06 : Le contenu d'un produit est d'un seul type : pack, contenu ou accessoire.
RP07 : Un produit est décrit par zéro, un ou plusieurs descriptifs de produit (descriptif complet, résumé, etc.)
RP08 : Un descriptif de produit décrit un seul produit
RP09 : Un descriptif de produit est traduit dans une ou plusieurs langues
RP10 : Un produit est représenté par une ou plusieurs images
RP11 : Un produit est représenté par une seule image par défaut

Gamme :
RG01 : Une gamme contient au moins un produit
RG02 : Un produit est contenu dans zéro, une ou plusieurs gammes
RG03 : Pour chaque langue, la gamme porte un seul nom
RG04 : Une gamme est décrite par zéro, un ou plusieurs descriptifs de gamme (descriptif complet, résumé, etc.)
RG05 : Un descriptif de gamme décrit une seule gamme
RG06 : Un descriptif de gamme est traduit dans une ou plusieurs langues
RG07 : Une gamme est représentée par une ou plusieurs images
RG08 : Une gamme est représentée par une seule image par défaut

Catégorie :
RC01 : Une catégorie contient zéro, un ou plusieurs produits
RC02 : Une catégorie contient zéro, une ou plusieurs catégories filles
RC03 : Une catégorie possède une ou plusieurs catégories parentes
RC04 : Le nom d'une catégorie est traduit dans une ou plusieurs langues
RC05 : Pour chaque langue, la catégorie porte un seul nom
RC06 : Une catégorie est décrite par zéro, un ou plusieurs descriptifs de catégorie (descriptif complet, résumé, etc.)
RC07 : Un descriptif de catégorie décrit une seule catégorie
RC08 : Un descriptif de catégorie est traduit dans une ou plusieurs langues
RC09 : Une catégorie est représentée par une seule image

RD01 : Une image est décrite par un seul descriptif (une légende)
RD02 : Le descriptif d'une image est traduit dans une ou plusieurs langues


Précisions sur les types de contenu d'un produit :
- Un pack est un groupe de produits qui sont proposés ensemble de façon occasionnelle. Il est possible de séparer les éléments du pack sans ouvrir le carton d'emballage.
- Un contenu est l'ensemble des produits individuels qui sont inclus dans le carton d'emballage du produit parent mais qui ne sont pas montés sur le produit parent. Il est possible de séparer les éléments du contenu uniquement en ouvrant le carton.
- Un accessoire est un produit individuel inclus dans le carton d'emballage et monté sur le produit parent. Il n'est possible de retirer un accessoire qu'en ouvrant le carton et en démontant le produit parent.


J'en ai profité pour ajouter les règles RD01 et RD02, relatives aux légendes des photos de produit. Ces règles figuraient sur le MCD mais n'étaient pas dans les règles de gestion.

La règle RP01 peut paraître étrange mais c'est une conséquence du mode de gestion des produits du fournisseur principal. Il réutilise parfois la même référence pour désigner un nouveau produit lorsqu'un ancien produit n'est plus fabriqué... Cette façon de faire est assez aberrante ; j'en viens à penser qu'il n'utilise pas de système informatisé de gestion, qui lui empêcherait de pratiquer de la sorte. Pour ma part, je suis obligé d'en tenir compte, et donc de créer un identifiant unique différent de la référence du produit.

Suite à cela et à la remarque sur la règle RP05 - il s'agit effectivement d'une relation composant/composé - j'ai modifié le MCD comme ceci :



Concernant la gestion multilingue, j'ai hésité sur le meilleur moyen de procéder, de façon à rationaliser les futures tables. J'ai hésité entre votre solution et celle de François. J'hésite encore, d'ailleurs. Le but était de mutaliser et de rassembler tous les noms dans une table et tous les descriptifs dans une autre, sans "disperser" les données textuelles dans une multitude de tables séparées.
Dans l'ancienne version de la base, j'utilisais votre approche et cela fonctionnait bien.

Le slug est, par définition, unique. Il correspond à une URL unique dans le site. Effectivement, et sauf accident, il n'y aura donc une catégorie, une gamme et un produit ne porteront jamais le même nom et n'auront donc pas le même slug. Cela voudrai dire qu'une URL peut diriger le visiteur vers 2 pages différentes, ce qui est impossible.

Voici quelques exemples :
Une catégorie "Bougies" donne un slug "bougies" et une URL unique "https://lemagasindelabougie.com/fr/bougies"
Une catégorie "Cierges" donne un slug "cierges" et une URL unique "https://lemagasindelabougie.com/fr/cierges"
Une gamme "Bougies Bizarres" donne un slug "bougies-bizarres" et pourrait donner une URL unique du type "https://lemagasindelabougie.com/fr/bougies-bizarres". A noter qu'en cas de doublonnage de noms dans 2 langues différentes (ce qui paraît assez improbable), le "/fr/" permettrait d'affirmer l'unicité de l'URL. Rien n'empêcherait aussi d'ajouter l'arborescence des catégories dans l'URL ("https://lemagasindelabougie.com/fr/bougies/bougies-bizarres") pour assurer son unicité.
Une gamme "Cierges de luxe" donne un slug "cierges-de-luxe" et pourrait donner une URL unique du type "https://lemagasindelabougie.com/fr/cierges-de-luxe".
Un produit "Bougie Bizarre rose et bleue de 10 cm" donne un slug "bougie-bizarre-rose-et-bleue-de-10-cm" et pourrait donner une URL unique du type "https://lemagasindelabougie.com/fr/bougie-bizarre-rose-et-bleue-de-10-cm".

Je vais modéliser votre solution de gestion multilingue dans une autre version de MCD.

Vincent

[aras-vbo]

François,

Selon Vincent, la collision des noms est possible, notamment en ce qui concerne les slugs et c’est un souci.

Même si la collision est possible si deux termes possèdent la même traduction dans deux langues différentes, il est quasiment impossible que deux éléments (catégorie, gamme ou produit) possèdent le même slug.
Le gros avantage de regrouper tous les intitulés (noms) dans une même table est effectivement de pouvoir poser une contrainte d'unicité plus facilement que s'il fallait mettre en place une contrainte d'unicité sur trois tables différentes.
Par contre, l'avantage de scinder les noms dans une table par type (catégorie, gamme ou produit) est qu'il est plus simple de faire des requêtes. Il n'est pas nécessaire de joindre une multitude de tables, par exemple pour extraire seulement les noms des catégories en français. Toutefois, je peux envisager de créer des vues pour reproduire ce comportement.

Portez-vous bien

Vincent

[fsmrel]

Ave,

l'avantage de scinder les noms dans une table par type (catégorie, gamme ou produit) est qu'il est plus simple de faire des requêtes. Il n'est pas nécessaire de joindre une multitude de tables, par exemple pour extraire seulement les noms des catégories en français. Toutefois, je peux envisager de créer des vues pour reproduire ce comportement.

Les deux approches sont possibles, donc retenez celle que vous « sentez » le mieux.

Cela dit, en conservant la table NOM, par le biais des vues vous pouvez définir des tables virtuelles par type (catégorie, gamme ou produit).

Dans le post #6 de la discussion Internationalisation des données (i18n) , j’ai proposé la requête suivante :

Code SQL :

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

1
2
3
4
5
SELECT CategorieCode, LangueNom, Nom, Slug 
FROM   CATEGORIE AS c 
  JOIN NOM_CATEGORIE AS n ON n.CategorieId = c.CategorieId
  JOIN NOM AS e ON n.NomId = e.NomId
  JOIN LANGUE AS l ON e.LangueId = l.LangueId ;

On peut l’encapsuler dans une vue :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE VIEW CATEGORIE_V
AS 
SELECT CategorieCode, LangueNom, Nom, Slug 
FROM   CATEGORIE AS c 
  JOIN NOM_CATEGORIE AS n ON n.CategorieId = c.CategorieId
  JOIN NOM AS e ON n.NomId = e.NomId
  JOIN LANGUE AS l ON e.LangueId = l.LangueId
;

Et pour extraire seulement les noms des catégories en français, c’est très simple :

Code SQL :

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

1
2
3
SELECT * 
FROM   CATEGORIE_V
WHERE  LangueNom = 'français' ;

L’utilisation des vues permet bien des choses, mais je ne voudrais pas trop vous influencer...

Sur le plan santé, ça va un peu mieux merci.

Bon courage à vous !