bonjour, j'etais plein d'une saine certitude en ce qui concerne la gestion de mes articles, mais une discussion que j'ai eu sur un autre post me plonge dans le doute. pour commencer, voici mon "cahier des charges" :

- j'ai une serie de fiches, rangee dans une ou plusieurs categorie, ecrite dans un langage style bbcode/spip/wikipedia pour la mise en forme, avec codage des caractere sepciaux avant affichage
- tout le monde peut creer / modifier un article, mais je verifie avant de publier. accessoirement, j'aimerais qu'il soit possible de faire / modifier un article en plusieurs fois, ie de pouvoir laisser un article "en plan", inachevé sans que cela soit vu par les visiteurs.

donc a priori :

- pour creer l'article, je dois l'afficher, mais aussi afficher les categorie qui le contiennet, l'auteur, + d'autres infos -> bcp d'appels a la base
- dans tous les cas, je dois avoir, me semble t il, 2 versions du meme article : la version "presentable", et la version "en developpement" ( que ce soit pour cause de travail en cours ou d'attente de validation de ma part )
- mon systeme de codage du texte fait que le contenu resultant pour l'affichage differe sensiblement de ce que l'utilisateur a tapé. or, pour pouvoir modifier un article dans de bonne condition, il faut qu'il retrouve ce qu'il a tapé, ie l'article dans mon pseudo langage avec des letres normales.
- le codage pseudo code -> html me semble forcement un peu bourrin, je n'imagine guere le faire a chauqe affichage de l'article.

c'est pourquoi j'ai choisi la solution d'avoir :

- une version de mon article dans la base, exactement tel qu'il a été tapé dans le formulaire
- une deuxieme version "en dur", cad ecrite dans un fichier, pour soulager le serveur, et pour disposer en permanence d'une version "presentable" en toute circonstance, independamment des modifs que j'apporte a l'article.

simplement on me fait remarquer, a juste titre, que cela multiplie par 2 la place prise par mes articles, et peux poser des problemes pour la gestion du design.
pour le design, comme mes menus / interface commune aux article sont appelés via des includes, et que je gere tout les styles dans une feuille css, je ne e fais pas trop de souci. dans un cas tres extreme, je pourrais toujours regenerer tous les articles en dur.

pour la place, je pense que c'est un sacrifice necessaire pour arriver a ce que je souhaite.

je me doute bien qu'il n'y a pas de reponse parfaite, mais j'aimerais savoir ce que vous en pensez. est ce vraiment stupide d'avoir une version "en cache" ? en fait, je ne sais pas estimer a partir de quel moment une requete ou une operation ( codage de mes articles, par ex ) devient reellement bourrine pour le serveur.

le debat est ouvert, merci a vous !

J'ai des raisons de croire que tu n'auras pas nécessairement 20000 articles à gérer de la sorte : dans cette optique, je ne vois pas vraiment ce qui t'empècherait d'avoir une table "article_temp" où tu stockerais les articles en cours d'élaboration : une fonction de mise à jour pourrait, une fois le résultat souhaité atteint, mettre à jour la table définitive et supprimer l'entrée de la table article_temp.

pas faux, meme si ca rajoute qq contraintes un peu lourde sur un truc qui me semble etre deja assez tordu. et puis quid de la charge du serveur ? dans la mesure ou justement je n'aurais pas 200000 articles, je peux me permettre de perdre un peu de place. je me doute, comme je le disais, qu'il y a d'autre maniere de proceder, ma question serait plutot de savoir si la mienne est vraiment stupide ( cad si elle a des inconvenients lourd que je n'ai pas envisagé ), ou finalement si ca se tient.

À première vue je dirais que ça se tient très bien. MySQL est capable de supporter une montée en charge importante. L'optimisation de ton code et des requêtes optimisées feront le reste.

quand je demandais si ca se tient, je parlais de ma methode ...
ok, comme je le disais je ne savais pas estimer ce qui etait lourd de ce qui ne l'etait pas. et dans le cas de mon codage, que je devrais du coup faire " a la volée", tu penses que ca passe aussi ?

À mon avis oui. Ta méthode n'a rien d'une hérésie. Il faudrait faire des benchmarks pour avoir une idée plus précise, mais à priori, je ne vois pas de contre-indication.

ouf, tant mieux. d'autant plus qu'il faut compter avec le facteur flemme sachant que mon truc est deja presque operationnel. mais je retiens l'idee de la base pour article temporaire ( simple; mais il fallat y penser ) si d'aventure j'en avais besoin. accessoirement, il me semble que la mise en cache peut apporter au niveau du referencement ?

Ce qui t'aidera beaucoup pour le référencement, c'est la réécriture d'url pour celles qui comportent des paramètres. La mise en cache va surtout apporter des performances au niveau des délais de chargement de page.

compris, c'est ce que je voulais dire, vu que du coup mes pages en cache ne comporte pas de parametre dans l'url. merci bien !

Comme déja abordé...
C'est difficile de juger si un système de cache avec des pages en dur, permettra de sensiblement accélerer l'accès à un article.
Si la db est correctement conçue, l'affichage d'un article devrait pouvoir se faire avec un nombre minimal de requête, donc je ne suis pas sûr qu'une page en dur apporte un réel avantage.
Cela dépendra surtout de la complexité des opérations à effectuer pour réaliser un affichage.
Comme Cyrano te l'a dit la seule façon de savoir c'est de faire des benchmarks