Discussion :

[vallica]

Bonjour tout le monde,

J'ai une question simple à propos d'un MCD sur lequel je bosse :

J'aurais dans mon application des utilisateurs qui auront pas mal d'attributs, comme par exemple couleur de cheveux, couleur des yeux, niveau d'études, etc. la liste est longue.

A la base, j'aurais fait ma table utilisateurs dans laquelle j'aurais placé des attributs tel que :

id_couleur_cheveux
id_couleur_yeux
id_niveau_etude

puis j'aurais eu 3 tables, respectivement couleur_cheveux, couleur_yeux puis niveau_etude avec la structure suivante :

couleur_cheveux(id_couleur_cheveux,libelle_couleur)

Voilà pour la solution la plus évidente qui me venait à l'esprit, seulement je me suis dit que ca allait être lourd de faire 20 tables de ce style si j'ai 20 critère sur mes utilisateurs.

Je me suis dit alors, que je pouvais faire une table qui regrouperait mes 20 critères et qui aurait la structure suivante :

table_multi_criteres(id_critere,cle_critere,valeur_critere)

voici un exemple de tuple de cette table :

Code :

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

1
2
3
4
5
6
7
8
9
 1 | couleurCheveux | Brun
 2 | couleurCheveux | Blond
 3 | couleurCheveux | Roux
 4 |    couleurYeux   | Noir
 5 |    couleurYeux   | Vert
 6 |    niveauEtude   | Bac
 7 |    niveauEtude   | Bac+1
.....

Bref cette table contiendrais tous les critères applicables à un utilisateur, et ma table utilisateurs quant à elle contiendrait autant de clés étrangères que de critères applicables.

Je suis donc face à ces deux architectures mais je ne sais pas laquelle choisir, j'ai très envie d'utiliser la seconde car elle me parait beaucoup plus souple : 1 seule table quelque soit le nombre de critères, mises à jours facilitées, etc.

Serait-ce le bon choix d'après vous ?

[Soutou]

Oui ça me parait bien, d'autant plus que si d'autres critères arrivent dans le temps il suffit d'ajouter des lignes.
Tu aurais ainsi 3 tables Utilisateur qui contient les données propres et uniques de chaque personne (nom, age, etc.), la table multicritere et la table qui relie les deux précédentes pour exprimer qu'une personne est associée à plusieurs critères.

[vallica]

Bonjour,

Tout d'abord merci beaucoup pour ta réponse, je commençais à croire que je n'en aurais pas du coup j'ai fait ma base en choisissant cette solution sauf que moi j'ai mis en dur dans la table Utilisateur toutes les clés étrangères faisant réference à un critère.

Du coup je n'ai pas la table qui fait la relation entre Utilisateur et Critere, mais c'est sur que c'est moin souple niveau évolutivité car si j'ajoute un critère je dois aussi faire un alter table sur la table Utilisateurs pour ajouter une nouvelle clé étrangère...

[Soutou]

Je serais toi je reviendrais en arrière car ta solution va générer pas mal de problèmes notamment dans la présence de nombreuses valeurs NULL.

tables

utilisateur(id_util, nom, age...)
multi_criteres(id_critere,cle_critere,valeur_critere)
caractéristiques(id_util#,id_critere#)

# : clé étrangère

[vallica]

C'est sur que la mesure où un utilisateur ne sera pas tenu de compléter son profil à 100%, j'aurais des NULL.

Merci pour ton intervention, je vais revoir mon schéma de cette manière.

Bon week-end