Discussion :

[hatembr]

Bonjour,

Je suis en train de faire une étude pour la refonte d'un site de rencontres. La question qui me tracasse un peu c'est la façon de structurer données décrivant les profils des utilisateurs.

Le profil d'un utilisateur est composé d'au moins 70 champs groupés selon des catégories (Look, Habitudes, Sorties ...) avec des champs pouvant avoir (pour certains) 1 valeur ou plus.

Par exemple:

Où est ce que vous préférez sortir:
1. Ciné
2. Restau
3. Théâtre ...

Il y a donc la possibilité de créer une table pour chaque groupe (table_look, table_sorties...) avec les différents champs et avec des double ou triple champs pour ceux qui acceptent les valeurs multiples (sortie1, sortie2, sortie3 ...).
Le site dans sa version actuelle est fait de cette façon, la limite réside dans l'évolutivité du profil. L'ajout d'un champ implique des changements divers.

La deuxième manière de faire que j'ai déjà vu des dév utiliser dans une société dont je ne donnerai pas le nom, est de créer une table pour chaque champ. Leurs BDs gèrent des millions de lignes.
Cela donnerait une BD avec quelques 70 tables comportant 3 colonnes (id, champ, valeur_champ), mais garantit :
1. une certaine facilité pour maintenir les champs
2. un nombre de jointures limité en fonction des champs qu'on a besoin d'extraire

La 3ème façon à laquelle j'ai pensé, c'est de stocker le tout dans une seule table (id, champ, type, valeur) où le type définit la catégorie d'information à lire (Look, Habitudes ...)
L'incinvénient c'est que la table aura un volume énorme pouvant ralentir l'exécution du site.

Voilà, c'est un choix décisif qui doit garantir une rapidité d'exécution avec une base de données assez volumineuse et en même temps, il doit faciliter la maintenance du site.

Est-ce quelqu'un pourrait commenter ces différentes façons de faire et proposer une meilleure structure s'il en existe ?

[jeca]

Bonjour,

Personnellement, je prends la 3è solution qui permet d'ajouter une caractéristique sans avoir à toucher une seule ligne de programme.
C'est à dire :
table utilisateur :
id
nom
...

table caracteristique
id
libelle
...

table caracteristique_utilisateur
id_utilisateur
id_caracteristique
valeur
...

[hatembr]

est-ce qu'à terme ça ne ralentirait pas le site ?
surtout pour faire du matching ou deux copies la table devront être utilisées dans la même requete ?

[jeca]

Désolé, mais j'suis qu'un 'boeu' de Francé moyen, donc 'matching', connais point.
D'autre part, dans une requête, on extrait des informations d'une ou plusieurs tables, donc :

deux copies la table devront être utilisées dans la même requete ?

comprend pas non plus.

[s.n.a.f.u]

C'est une sorte d'auto-jointure.
Un truc du style :

Code sql :

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

SELECT A.Id, B.Id FROM maTable AS A INNER JOIN maTable AS B ON A.unCritere = B.unCritereAussi

Et si les indexes sont bien posés, je ne pense pas que cela fasse une grosse différence en termes de perfs

[Sergejack]

Les méthodes 2 et 3 vont t'imposer soit

1) de faire des query avec plein de jointures

SELECT infobase.*, info_001.value, info_002.value, ...
FROM infobase, info_001, info_002 ....

2) de n'employer aucune table regroupant plusieurss informations (nom + prénom + date de naissance, par exemple) et en utilisant des query dont plusieurs lignes formerait un résultat logique.

SELECT info.id, info.value, info.champ, info.type
FROM info
ORDER by info.id, info.champ

et où faire des jointures pourrait se révéler fastidieux (car type dynamique).