Bonjour,
Je souhaiterai avoir votre avis sur l'organisation de ma BDD pour gérer les utilisateurs avec CakePHP.
Pour faire simple, chaque utilisateur à des informations de base comme son email, son username, password...
Puis je dois également gérer tout un tas de statistiques sur ces utilisateurs avec des counter cache (post_count, sell_count....)
Enfin je dois gérer les préférences de l'utilisateur comme les notifications par email, la langue, la time zone, la devise...
Me conseillez-vous de faire une grande table users et pour chaque requête faire un SELECT au maximum restreint, ou bien de spliter ma table en users, user_stats, usersettings ?
Ce dernier cas m'impose des jointures alors que j'ai déjà un grand nombre de requêtes et de jointures à effectuer par page, d'où mon apprehension d'en rajouter. De plus, il y'aura donc autant de ligne pour chaque user*** que de users.
Comment feriez-vous cela sachant que la BDD est très grosse, et qu'il y a beaucoup de requêtes par pages ? La performance est donc le critère numéro 1, puis vient la maintenance du code. Comment pensez-vous que des sites comme facebook, twitter, ebay... gére cela ?
Merci pour vos retours.
2 réponses
Bonjour,
Tout d'abord, concernant ta question : "Comment font facebook, twitter, ebay, etc. ?".
Ce sont des entreprises dont tout tourne grace à leur(s) plateforme(s). Ils ont les moyens financiers pour avoir une quantité non négligeable de serveurs. Plusieurs milliers pour la plupart. Ceux-ci sont relativement puissant et ils ont mis en place un système de loadbalancing sur les serveurs HTTP, SQL et de fichiers. Arrivé à ce stade, plus de problèmes de performances vu que la quantité de RAM dépasse allégrment les 100 To et que le nombre de coeurs de procésseurs se compte en millier.
Dans ton cas, si les liaisons entre les tables sont 1 user <=> 1 usersettings, tu peux tout mettre sur la même table. Donc si tu as :
users hasOne usersettings et usersettings hasOne users pourquoi faire une jointure ? Ta base sera toujour moins volumineuse en mettant tout sur la même table quand créant deux tables plus petites. De plus ça te permet, lors du SELECT de ne charger qu'une table lors de la requete contre deux avec une liaison.
Un dernier point mais pas des moindres, si ton serveur est suffisament puissant pour gérer une base volumineuse de plusieurs millions/milliards de lignes tu n'alourdiras pas la charge en procédant ainsi. Après si ton SQL est sur un serveur avec un intel celeron mono coeur... la c'est pas garanti. Enfin tout dépend du moteur SQL qui est derrière. La plus part des moteur SQL "recent" fonctionne en multi thread ce qui accélère grandement la vitesse de traitement.
En espérant t'avoir été utile.
Merci TitLoW pour ta réponse.
Je suis du même avis que toi (étant donné qu'il s'agit d'un hasOne dans les 2 sens). J'ai toujours procédé ainsi mais comme j'ai vu des projets Github qui spliter la table je me suis demandais pourquoi, et si je ne mis prené pas mal. D'autant plus qu'en ayant poster ma question sur OpenClassroom j'ai eu une réponse me disant de spliter mais sans "vrai" argument.
C'est à dire que quand je met tout ce qui touche un user (préférences, stats, notification...) dans une même table ça me fait beaucoup de colone (pas terminé de lister, mais 30 voir 40). Une grosse partie est simplement binaire.
Je reste ouvert à d'autres avis.