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

[hatembr]

merci pr vos réponses.

Donc en gros, c'est la 3ème méthode qui serait la plus appropriée?
Ce qui va donner au moins 70 lignes par profil, à multiplier par quelques milliers d'utilisateurs.
Coté performances, comment peut-on savoir si ça peut ralentir ou pas ?

Par contre, j'ai pensé à isoler les informations les plus communes dans la table 'membres' à savoir: sexe, age, pays, ville, region, statut matrimonial.
C'est les infos les plus courament utilisées dans les recherches.
J'ai pensé à cela afin d'éviter de faire des jointures pour extraires ces infos basiques à chaque recherche ou affichage de profil et de laisser la grosse table pour l'affichage du profil détaillé ou le matching.

PS: @Mod. je me rends compte que j'aurai dû poster ça dans MySQL plutot que php&mysql

[Sergejack]

merci pr vos réponses.

Donc en gros, c'est la 3ème méthode qui serait la plus appropriée?
Ce qui va donner au moins 70 lignes par profil, à multiplier par quelques milliers d'utilisateurs.
Coté performances, comment peut-on savoir si ça peut ralentir ou pas ?

Par contre, j'ai pensé à isoler les informations les plus communes dans la table 'membres' à savoir: sexe, age, pays, ville, region, statut matrimonial.
C'est les infos les plus courament utilisées dans les recherches.
J'ai pensé à cela afin d'éviter de faire des jointures pour extraires ces infos basiques à chaque recherche ou affichage de profil et de laisser la grosse table pour l'affichage du profil détaillé ou le matching.

PS: @Mod. je me rends compte que j'aurai dû poster ça dans MySQL plutot que php&mysql

Ben avec ce choix, pour obtenir un profile entier tu devras faire 2 queries.
1 query pour récup les données générales
1 pour les lignes particulières

c'était mon point 2.

[hatembr]

oui tout à fait, c'était le point dont tu as parlé.

Mais je pense qu'en le combinant avec la méthode 3 à mon avis ça permet d'éviter de hardcoder les valeurs 'type' de ces champs ds php pour pouvoir les extraire plus tard: ça fait d'eux des champs faisant partie de la structure de la BD.
Pour le profil détaillé, il peut être lu en vrac et d'une manière générique, un peu comme un méta modèle (décrit dans l'un des tutoriaux sur le site).

[s.n.a.f.u]

merci pr vos réponses.

Donc en gros, c'est la 3ème méthode qui serait la plus appropriée?
Ce qui va donner au moins 70 lignes par profil, à multiplier par quelques milliers d'utilisateurs.
Coté performances, comment peut-on savoir si ça peut ralentir ou pas ?

Par contre, j'ai pensé à isoler les informations les plus communes dans la table 'membres' à savoir: sexe, age, pays, ville, region, statut matrimonial.
C'est les infos les plus courament utilisées dans les recherches.
J'ai pensé à cela afin d'éviter de faire des jointures pour extraires ces infos basiques à chaque recherche ou affichage de profil et de laisser la grosse table pour l'affichage du profil détaillé ou le matching.

PS: @Mod. je me rends compte que j'aurai dû poster ça dans MySQL plutot que php&mysql

J'ai pas tout lu, mais 70*1000 = 70000 lignes
C'est que dalle pour une base de données.

[jeca]

Ben avec ce choix, pour obtenir un profile entier tu devras faire 2 queries.
1 query pour récup les données générales
1 pour les lignes particulières

Avec ça (1 seule requête) :

Code :

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

1
2
3
4
$sql = 'SELECT utilisateur.id, utilisateur.lesChamps, caracteristique.libelle, caracteristique_utilisateur.valeur
        FROM utilisateur
        INNER JOIN caracteristique_utilisateur ON utilisateur.id = caracteristique_utilisateur.id_utilisateur
        INNER JOIN caracteristique ON caracteristique.id = caracteristique_utilisateur.id_caracteristique;

on récupère un profil complet, non ?

[hatembr]

J'ai pas tout lu, mais 70*1000 = 70000 lignes
C'est que dalle pour une base de données.

en effet avec 1000 membres c'est rien
mais qu'en est il des performances si la BD atteint 5000, 10000, 20000 ou plus de membres? je suis sur qu'on ressent la lourdeur de la BD avec des volumes comme ça, non ? (je n'ai jamais eu d'expériences avec de tels volumes de données)

[s.n.a.f.u]

en effet avec 1000 membres c'est rien
mais qu'en est il des performances si la BD atteint 5000, 10000, 20000 ou plus de membres? je suis sur qu'on ressent la lourdeur de la BD avec des volumes comme ça, non ? (je n'ai jamais eu d'expériences avec de tels volumes de données)

Ben... Y a pleins de paramètres en jeu...
Si tu grossis à ce point, tu auras peut-être des soucis en mutualisé à partir de 100000 (au pif). Mais comme ça marchera bien, tu passeras sur un serveur dédié plus costaud, et les perfs reviendront, etc...
C'est comme les programmes de maintenant : on optimise moins parce nous avons toute la patate nécessaire pour les faire tourner. Sinon, tout serait recodé en C. (hey les trolls qui arrivent à grands pas, j'exagère hein, c'est pour rire)

Pour exemple, sur des bases DB2 hébergées sur un mainframe, je ne me posais pas trop de questions en dessous du million de lignes...

[hatembr]

))

au fait j'aurais du préciser que c'est déja hébergé sur un serveur dédié debian/php5/mysql5

donc en fin de compte, il ne faut pas se poser de questions à moins d'atteindre des millions de profils ... c'est ça?

auquel cas il faudrait penser à changer de sgbd (oracle par ex)....

[s.n.a.f.u]

))

au fait j'aurais du préciser que c'est déja hébergé sur un serveur dédié debian/php5/mysql5

donc en fin de compte, il ne faut pas se poser de questions à moins d'atteindre des millions de profils ... c'est ça?

auquel cas il faudrait penser à changer de sgbd (oracle par ex)....

Des millions, tu y vas fort. Ton Debian n'est pas un mainframe IBM.

Mais pour 70000 et même 100 000, je pense que ça ira tranquille. Ca te laisse le temps de voir venir et de benchmarker tes requêtes.
... Et de m'embaucher quand tu en seras à 500 000 !

[hatembr]

MDR! et pkoi pas! mon souhait c'est d'atteindre un tel nombre d'abonnés!