Si on regarde le forum Trucs en vrac, on voit qu’il est annoncé 5314 threads.
Mais en fait, à l’intérieur, il n’y a plus que 5 pages!
Qu’est-ce qu’il s’est passé? C’était déjà comme ça dès le début de la V3?
C’est juste, j’avais pas remarqué. Et le vendredi, qu’une page aussi ( mais, mais, AAAAAAAAAAAAH!!! 
)
Par contre d’autres forums comme AnimeZone ( 23 pages ) ou Le Journal du Hard ( 80 pages ) ont l’aire d’être complets.
Perte d’info? ou trucs en vracs avait trop de messages et surchargeait la BD ?
Edit : c’est quand même bizarre parce que pour les stats ça a l’air que tous les threads de Trucs en Vrac sont pris en compte. Par exemple dans mes stats perso, j’ai 500 et qques messages dans Trucs en Vracs …
Apparemment le Recount & Rebuild a été fait (cf nombre total de message sur l’index).
Allez dans votre profil si vous avez posté un jour dans ces topics que vous pensez perdus, mais donc vous avez conservé le nombre de messages postés, faites “Trouver tous les messages de ce membre” ou alors via la fonction recherche.
Si vous ne trouvez rien, ce n’est effectivement pas présent, et peut être volontaire.
[quote name=‹ IDoine › date=’ 7 Nov 2004, 13:04’]Apparemment le Recount & Rebuild a été fait (cf nombre total de message sur l’index).
Allez dans votre profil si vous avez posté un jour dans ces topics que vous pensez perdus, mais donc vous avez conservé le nombre de messages postés, faites « Trouver tous les messages de ce membre » ou alors via la fonction recherche.
Si vous ne trouvez rien, ce n’est effectivement pas présent, et peut être volontaire.
[right][post=« 300174 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Hahaha. Je suis en train de foutre le display cut off sur 30 jours. A vous de le régler quand vous faites l’affichage (en bas) d’un forum !!
Egalement, oui Généralement, c’est pour soulager le temps de requêtes, j’avoue que j’ai toujours tout affiché (et IPB2 est enfin assez puissant pour le permettre, même sur un forum de 200 000 inscrits \o/).
Ok ok, j’ai vu le truc. Merci Caf pour l’info.
Donc les messages sont pas perdus, mais seulement cachés pour éviter de mettre à genou les machines. Donc au cas où, on remet ça sur 30 jours, et on s’en sert au besoin. Cool
[quote name=‹ Caféine › date=’ 7 Nov 2004, 13:06’]Hahaha. Je suis en train de foutre le display cut off sur 30 jours. A vous de le régler quand vous faites l’affichage (en bas) d’un forum !!
[right][post=« 300175 »]<{POST_SNAPBACK}>[/post][/right][/quote]Oh putain… j’en étais presque à me connecter à la base de donnée pour vérifier que c’est bon… Je ne comprennais pas pourquoi je n’avais pas plusieurs pages pour Cafzone Corner… Gomen
Bête question: le rebuild des nombres de posts d’un menbre a été fait en comptant réellement le nombre de sujets? c’était pas un champ à part? ipb compte le nombre de post comme ça aussi? ça veut dire qu’à chaque fois qu’on veut savoir combien de posts on a fait il fait une requête sur les millers de messages pour savoir combien ont été posté par le user?
Reflechis 2 seconde en preformance… Là tu l’as la reponse ?
Evidemment que c’est un champ dans la base… le mec qui fait un count() des posts pour chaque user pour un thread qui s’affiche merite une balle dans la tête.
[quote name=‘Donjohn’ date=’ 10 Nov 2004, 19:54’]Reflechis 2 seconde en preformance… Là tu l’as la reponse ?
Evidemment que c’est un champ dans la base… le mec qui fait un count() des posts pour chaque user pour un thread qui s’affiche merite une balle dans la tête.
[right][post=“301746”]<{POST_SNAPBACK}>[/post][/right][/quote]
Asbolument pas. Au contraire, il merite une medaille pour faire l’effort de pas denormaliser des trucs a tout va. Et niveau perfs du moment que ta database supporte les view, il y a aucun probleme a part dans les cas extremes. Un forum en est tres loin. Si on se refuse a le faire sur des DBs de 250 gig c’est pas pour raler parceque a 300 megs ca pourrait ralentir qqch :P.
Denormaliser c’est mal, quelle que soit la situation. A moins de vouloir le faire expres comme dans un cas ou tu as pas tous les messages mais tu veux un chiffre plus gros (ce qui est le cas pour la DB de cafzone, c’est un choix de pas avoir tous les messages qui correspondent au compte pour chaque user - because perte de donnees avec cafzone v1). Mais dans ce cas la c’est pas une denormalisation, c’est un champ qui a un sens different qui a rien a voir avec un count(*). Les limitations techniques d’un certains type de bases n’en enlevent pas moins le fait que c’est tres mal de denormaliser au niveau design de base de donnees, comme c’est tres tres mal de me pas avoir de contraintes de foreign key ou pire de ne pas les garantir (si la base le fait pas au moins faire l’effort au niveau appli).
Les infos doivent etre en un seul exemplaire, etre consistantes et jamais orphelines en cas de relation. Parfois dans des cas extremes (genre vraiment), on a super pas le choix et meme une view est pas suffisante (par exemple DB distribuee ou relation cross DB ou traffic fou mais dans ce cas la faut d’abord chercher a optimiser l’appli). Dans ce cas la, l’info doit etre verifiees avec des contraites a chaque mise a jour et dupliquee dans une transaction avec des triggers au niveau de la base elle meme pour n’avoir jamais une base en contradiction avec elle meme.
Ca c’est l’ideal, le reste ce sont des concessions a causes de limitations du soft de DB. Mais il faut pas presupposer a priori quelles seront ces concessions sur un feeling. Un des trucs les pire du design logiciel c’est de l’optimisation mal placee ou faite trop tot.
C’est pour ca que c’etait un champ dans ta base alors ? C’etait pour ne pas dénormaliser peut etre ?
MSSql ne pouvait pas supporter un tel traitement ?
Je troll, je sais, mais avec un systeme comme ca, tu as interet à avoir un beau serveur derriere et c’est pas le but d’IPB de demander un tel materiel (ils filent ca pour MySQL n’oublie pas, pas pour Oracle ou equivalent).
Pour un bête champ, c’est vraiment de la memoire/cpu gachée pour rien. Créer une vue par user pour chaque page, je trouve ca ignoble.
La question de dénormalisation d’un champ doit être traiter au cas par cas, ca a son utilité sans soucis. Mais dans ce cas précis, c’est sans appel pour moi : C’est affreux. Opinion personnelle
Les enfants, vous serez gentils de continuer en PM hein si ça devient technique comme ça. Ahem… :P"
j’aimerais bien voir les perfs avec une telle solution
ya des fois la normalisation faut pas la suivre comme un mouton 100% d’acord avec donjohn
[quote name=‹ Donjohn › date=’ 11 Nov 2004, 17:19’]C’est pour ca que c’etait un champ dans ta base alors ? C’etait pour ne pas dénormaliser peut etre ?
MSSql ne pouvait pas supporter un tel traitement ?
[right][post=« 302072 »]<{POST_SNAPBACK}>[/post][/right][/quote]
J’ai deja repondu pourquoi c’etait denormalise dans ma DB. C’etait parceque a cause du crash de la v1, il etait fait EXPRES de ne pas avoir le champ en synchro avec le contenu de la base. La similitude des schemas pour faciliter l’import etait aussi une consideration. Dans le cas de Mysql qui ne supporte pas les view l’argument perf peut etre tenu, mais j’aimerais avoir des preuves claires que la diff est significative et justifie la denorm. Mais c’est une concession a un bon design de DB qui doit etre prise en plein connaissance de cause.
Si tu as des views, dans ce cas particulier la question ne se pose meme pas. Les demandes en perfs pour une view de ce type sont minimes. Encore une fois, MySql ne supporte pas les view, c’est une autres histoire, ca justifie sans aucun doute la denormalisation mais ca ne l’excuse pas.
Ca prouve clairerement que tu n’as aucune idee de la maniere dont fonctionne une view dans une base de donnee. Tu n’as absolument pas besoin de faire ca, ca serait completement ridicule et effectivement completement debile. Dieu merci, une seule view pour ces infos (et d’autres d’ailleurs) suffit largement, les resultats seront caches et tu n’aura pas de probleme de perfs. Les perfs ne sont pas affectes puisque le resultat est le meme que de denormaliser sans dupliquer toi meme les donnee.
Un autre technique courament utilisee qui s’appliquerait assez bien dans certains des cas d’un forum est ce qu’on appelle les tables « pre-jointes » qui permettent de minimiser au maximum le cout de la jointure. A essayer bien avant de denormaliser…
Maintenant tous les travaux de recherche et tous les cours de DB du monde entier insiste bien sur le cote fondamental d’une base de donnee bien normalisee. En encore on parle ici que de la deuxieme/troisiemme forme normale et pas des 4 voire 5eme formes normales qui sont elles le sujet de debats bien plus enflames.
Ca veut pas dire que personne ne devrait jamais denormaliser, il ne s’agit pas d’etre un integriste de la normalisation non plus. C’est meme un aspect tres important d’un bon design de base de donnee et il y a plein plein d’articles sur les valeur d’une bonne denormalisation. Si il y a besoin d’ecrire un article c’est que ces cas sont loin d’etre triviaux meme si tout ne peut pas etre resolu par une base 100% normalisee. C’est une evidence. Les cas ou cela se justifie sont a evaluer au cas par cas bases sur des CHIFFRES de performance qui JUSTIFIENT la denormalisation. Pas sur une intuite.
Le comportement par defaut est : faire une base 100% normalisee et quand a ce moment la tu as des problemes de perfs, apres avoir epuise toutes les optimisation de query, tous les mecanismes de cache, tu denormalise. Base sur des faits. Tout les articles sur la denormalisation sont d’ailleurs sur la question « quand ne pas respecter la regle » c’est bien qu’il y a une regle a la base B) Comme pour toute regle quand on ne la respecte pas il faut:
- connaitre la regle
- savoir pourquoi la regle existe
- connaitre les consequences de ne pas respecter la regle
- savoir exactement pourquoi tu veux ne pas respecter la regle
Comme le resume un des liens ci dessous:
[quote]Denormalization should not be done early, however. It is a last desperate resort that one should turn to only after exhausting all other options (like query optimization, improved indexing, and database system tuning, all of which will be discussed later in the book). Normally, follow the simple rule:
When in doubt, normalize.[/quote]
ou encore:
et:
Quelques liens:
http://www.miswebdesign.com/resources/arti…hapter-3-4.html
http://www.databasedesign-resource.com/denormalization.html
http://www.tdan.com/i020fe02.htm
http://www.objectarchitects.de/ObjectArchi…es/i001fe02.htm
http://www.dmreview.com/article_sub.cfm?articleID=5251 (au titre evocateur: The Dangerous Illusion: Denormalization, Performance and Integrity)
http://www.dmreview.com/article_sub.cfm?articleID=5337 (part 2)
http://www.dbdebunk.citymax.com/page/page/622733.htm
http://www.dbpd.com/vault/9804date.htm
Un petit coup de google vous en donnera bien d’autre et vous permettra de vous faire une idee. Pour conclure, encore une fois, il s’agit pas de faire de la normalisation une religion mais de absolument savoir ce que l’on fait et denormaliser seulement en dernier recour. Alors ca devient une solution parfaitement valable et acceptable.
La theorie c’est joli mais voila… la demonstration avec un exemple concret
Puisqu’on en est a donner des exemples concrets allons y. Sur la DB cafzone avec ses 293 207 messages et ses 8728 users, sur un Celeron 1.7 Gig avec 512 megs (loin d’etre un foudre de guerre). MSSQL.
SELECT * FROM ForumMessages
INNER JOIN Users ON Users.UserId=ForumMessages.UserId
WHERE FTId=38
Ici on utilise le champ denormalise. Thread typique avec 77 messages, loin d’etre ridicule sachant que concretement les threads sont limites a 30 messages par pages. Temps d’execution: 20 milisecondes.
La query suivante:
SELECT * FROM ForumMessages
INNER JOIN Users ON Users.UserId=ForumMessages.UserId
INNER JOIN MessagesPerUser ON MessagesPerUser.UserId=ForumMessages.UserId
WHERE FTId=38
Ici on utilise pas le champ denormalise, on a une indexed view MessagesPerUsers qui est toujours a jour et consistante. Temps d’execution: 20 millisecondes.
La difference est en dessous de la milliseconde. Et on est avec TOUTES les options de trace et de debug activees, a 20 millisecondes par query. Conclusion: denormalisation inutile. Et c’est avec 30 secondes sur le serveur sans se faire chier a optimiser les queries. Voila. Stou.
Avec 100 threads a la fois (ou on selectionne tout) on obtient 250 millisecondes dans un cas (denorm), 270 millisecondes dans l’autre cas (pas denorm). Il y a bien evidement une difference, le contraire aurait ete surprenant. Mais elle est minime.
100% d’accord avec Glop.
Une BDD bien normalisée avec avec les bonnes contraintes d’intégrité là où il faut, c’est toujours ca de moins à faire en soft, et on a la garantie que ca sera toujours intègre, une erreur de manipulation ou un bug dans le code de génération de SQL étant si vite arrivé…
Y’a que du bon à garder son schéma normalisé, faut vraiment une excellente raison pour que ca ne soit pas le cas. Dénormaliser une BDD afin de gagner une paire d’heure de conception ou quelques ms lors de l’execution, c’est la certitude de perdre des heures voire des journées à mettre les mains dans le cambouis en cas de bug, de plantage ou de problème quelconque.
Proposition de suite de la discussion dans Forums Cafzone > DevZone > Segmentation Fault : [SQL, MPD] La normalisation
HELP !! truc bizarre : je viens de remarquer que mon compteur de posts a perdu environ 30 posts !!!
[quote name=‹ Bishop[DS] › date=’ 30 Nov 2004, 10:44’]HELP !! truc bizarre : je viens de remarquer que mon compteur de posts a perdu environ 30 posts !!!
[right][post=« 308482 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Rien d’anormal. J’ai fait un recompte + synchro des forums. Du coup tous a été recompté sur les messages réellements présents dans le forum.
ok danke
Bon en principe avec ce message on devrait voir s’afficher un rond et grassouillet 500 messages ainsi que mon nouveau titre de Lord Jedi Geek.
Mais attention hein ! Je fais vraiment ça pour me dévouer et voir si le tout marche
Edit : Voilà on a la réponse, le titre s’update pas automatiquement, par contre les carrés oui.