Bonjour,
Je suis en train de réfléchir à la meilleure structure pour stocker le profil d'un membre sur un site de rencontres style meetic.
Le profil comportera une soixantaine de critères et donc là se pose le problème : j'hésite entre 3 possibilités :
1. stocker tous les champs ds la meme table "membre"
=> probleme car les recherches se feront sur une soixantaine de champs avec toutes les combinaisons possibles et imaginables, alors que les index ne peuvent contenir qu'un max de 16 champs.
2. eclater la table en plusieurs tables, chacune comportera un certain nombre de champs selon la catégorie de l'info (generalités, look, préférences ...)
=> probleme 1: les index comme pour le point 1 car certaines infos telles que les preferences depassent les 16 criteres, à moins d'eclater les tables à un deuxieme niveau (preferences1 et peferences2)
=> probleme 2: lourdeur au niveau des requetes à cause des jointures qui seront plusieures avec en plus d'autres tables annexes qui seront forcéement incluses ds les requetes
3. utiliser une structure générique du type (id_categorie, id_champ, valeur_champ, id_user) qui permettra de stocker les infos en vrac ds la meme table et qui sera indexé sur les 4 champs mais qui à terme risque de saturer la BD et le HD du serveur.
Voilà, je n'ai aucune idée sur les possibles performances de chaque méthode sur un grand nombre de membres stockés ds la BD, mais le choix doit être définitif, tout ce que je sais c'est que j'ai lu qqe part une interview du fondateur de meetic qui a expliqué qu'à un moment donné, ils ont du dénormaliser leurs BD et stocker des données redondantes afin d'optimiser les temps d'accès .
Est-ce que qqun peut me donner son avis là dessus ? quel est le meilleur choix à votre avis ?
Merci d'avance
PS: j'utilise MySQL4 sur mon serveur![]()
Partager