Bonjour,
Je suis en train de mettre en place un système de commentaire pour un site à grand public(enfin, pas vraiment 30000 visite par mois).
J'ai un différent avec mon maitre de stage et j'essaye de trouver la meilleure solution:
le site veut que les membres puissent ajouter des commentaires sur du contenu. Au niveau de la page de visualisation, on souhaite afficher par ordre décroissant, le login du membre, la date et le commentaire.
Pour le moment il y a deux tables qui sont en gros
Membre(MEmbre_ID, Login, Pass, Email);
Contenu(Contenu_ID, et d'autres champs qui ne sont pas bien interessant pour mon pb);
Ma table commentaire serait celle ci
commentaire(Commentaire_ID, date, texte, #Contenu_ID, #Membre_ID);
La table commentaire de mon maitre de stage est comme ça:
commentaire(Commentaire_ID, date, texte, #Contenu_ID, #membre_ID,Login);
Je lui ai ressorti mes cours de conception pour lui dire," ta table n'est pas en 3eme forme normale".
Voila sa réponse, "c'est vrai, ma table n'est pas bien faite, mais on est un site a grand public donc imagine que la page qui affiche les commentaires d'un contenu est vu en meme temps par 1000 personnes, ma requete mettra moins de temps que la tienne.
(je dois faire une jointure pour afficher le nom de la personne, pas lui).
Respecter les normes de conception s'est très important, mais le plus important c'est le temps d'execution et la manière dont on doit utiliser les données plus tard".
Personelement, sa table ne me gene pas, mais d'ici 1 mois j'ai une soutenance pour mon stage, et si mon jury se compose de profs de base de données, ca ne va pas leur plaire....
POuvez vous me donnez votre avis?
Merci
la communauté d'entraide francophone dédiée au PHP
Optimisation de requete
Techniquement, ton maître de stage a raison et tort en même temps. C'est vrai que pour un commentaire, il va économiser une jointure : mais pour la mise à jour d'un profil. il devra le faire à deux endroits différents avec une requête de plus.
La redondance n'a pas lieu d'être dans une base de données convenablement conçue. D'autre part, le problème de rapidité en montée en charge ne sera pas si important si les colonnes sont correctement indexées : il y a certes les clés primaires, mais il faut également indexer les clés étrangères. Même si la requête sera moins rapide avec jointure que sans, avec de bons index, ça va se mesurer en micro-secondes : même multiplié par 2000 utilisateurs, il n'y a pas de quoi fouetter un chat.
La redondance n'a pas lieu d'être dans une base de données convenablement conçue. D'autre part, le problème de rapidité en montée en charge ne sera pas si important si les colonnes sont correctement indexées : il y a certes les clés primaires, mais il faut également indexer les clés étrangères. Même si la requête sera moins rapide avec jointure que sans, avec de bons index, ça va se mesurer en micro-secondes : même multiplié par 2000 utilisateurs, il n'y a pas de quoi fouetter un chat.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse 
Administrateur PHPfrance |
3088 Messages
Bon, ben Cyrano l'a dit à ma place : c'est de l'ordre de la microseconde. Allez, disons 0.001s pour 10000 commentaires, mais pas plus.
Selon la version de MySQL il se peut qu'il effectue la jointure sur tous les enregistrements potentiels et pas seulement les n plus récents. Ce que tu peux faire pour y remédier est d'utiliser une table dérivée
À noter qu'en dessous de plusieurs dizaine de milliers d'enregistrements tu ne verras pas d'amélioration substantielle en utilisant cette méthode.
Ah, si, une chose : mets un index sur date, ça permet de récupérer les n plus récents (ou plus anciens) très rapidement : à peu près instantané que ce soit avec 1000 ou 1 000 000 de commentaires.
Selon la version de MySQL il se peut qu'il effectue la jointure sur tous les enregistrements potentiels et pas seulement les n plus récents. Ce que tu peux faire pour y remédier est d'utiliser une table dérivée
Code : Tout sélectionner
SELECT c.Commentaire_ID, c.date, c.texte, Contenu_ID, c.Membre_ID, m.Login
FROM (
SELECT Commentaire_ID
FROM commentaire
ORDER BY `date` DESC
LIMIT 20
) AS t
JOIN commentaire c USING (Commentaire_ID)
JOIN Membre m USING (Membre_ID)
ORDER BY `date` DESCAh, si, une chose : mets un index sur date, ça permet de récupérer les n plus récents (ou plus anciens) très rapidement : à peu près instantané que ce soit avec 1000 ou 1 000 000 de commentaires.
C'est le grand débat entre théorie et pratique (cf. ma signature 
)
Si on respecte Merise et les normes de construction d'une base relationnelle, ta solution est effectivement la bonne : un minimum de redondance dans la base. L'intérêt derrière tout cela est naturellement d'économiser de la place et de simplifier la maintenance et mise à jour : si une donnée n'est présente qu'une fois dans ta base elle n'est à modifier qu'en un seul endroit.
Maintenant la pratique : combien de fois cette donnée sera-t-elle modifiée par rapport au nombre de fois où elle aura besoin d'être consultée ? et la place qu'elle occupe est elle suffisament conséquente pour justifier qu'elle ne soit surtout pas dupliquée ?
Qu'en est-il du contexte ?
- Le login/pseudo ne changera théoriquement jamais.
- L'espace occupé par un varchar est négligeable (sans parler des évolutions qu'il y a eu en matière de capacité de stockage des disques)
- Tu évite une jointure sur une autre table
- Tu peux archiver/purger la liste des utilisateurs qui ne viennent plus sans pour autant devoir supprimer leurs commentaires.
- Tu pourras ouvrir le commentaire aux utilisateurs non authentifiés, en leur permettant de saisir leurs pseudos sans avoir à les enregistrer dans ta table users
- ...
Bref, tout ça pour dire qu'il peut y avoir des avantages à ne pas respecter les convenances
Maintenant, ta jointure se fera sur une clé primaire, tes tables seront en principe indéxées et les temps de réponses dépendront du volume de données de la table qu'il vous faut estimer, indépendament du nombre de visiteurs. La différence sera assez négligeable je pense, mais tu peux toujours faire un script bidon pour remplir ta table de données et faire une comparaison
)Si on respecte Merise et les normes de construction d'une base relationnelle, ta solution est effectivement la bonne : un minimum de redondance dans la base. L'intérêt derrière tout cela est naturellement d'économiser de la place et de simplifier la maintenance et mise à jour : si une donnée n'est présente qu'une fois dans ta base elle n'est à modifier qu'en un seul endroit.
Maintenant la pratique : combien de fois cette donnée sera-t-elle modifiée par rapport au nombre de fois où elle aura besoin d'être consultée ? et la place qu'elle occupe est elle suffisament conséquente pour justifier qu'elle ne soit surtout pas dupliquée ?
Qu'en est-il du contexte ?
- Le login/pseudo ne changera théoriquement jamais.
- L'espace occupé par un varchar est négligeable (sans parler des évolutions qu'il y a eu en matière de capacité de stockage des disques)
- Tu évite une jointure sur une autre table
- Tu peux archiver/purger la liste des utilisateurs qui ne viennent plus sans pour autant devoir supprimer leurs commentaires.
- Tu pourras ouvrir le commentaire aux utilisateurs non authentifiés, en leur permettant de saisir leurs pseudos sans avoir à les enregistrer dans ta table users
- ...
Bref, tout ça pour dire qu'il peut y avoir des avantages à ne pas respecter les convenances
Maintenant, ta jointure se fera sur une clé primaire, tes tables seront en principe indéxées et les temps de réponses dépendront du volume de données de la table qu'il vous faut estimer, indépendament du nombre de visiteurs. La différence sera assez négligeable je pense, mais tu peux toujours faire un script bidon pour remplir ta table de données et faire une comparaison
Ce n'est pas en améliorant la bougie que l'on a inventé l'ampoule...