mettre de grands articles dans une BDD ?

[nyl auster]

Bonjour à tous

Nous sommes en train de construire un site internet (sur les jeux vidéo pour donner une vague idée de l'organisation de notre site), et je suis chargé du côté technique. Etant débutant en php/sql, je me pose pas mal de questions.

Actuellement, les pages d'articles sont en réalité des pages statiques: je les génère à travers une adminsitration php qui contient un sorte de "template" de la page, qui se remplit automatiquement avec la base de données grâce aux variables qu'il contient. Je me contente ensuite d'écrire dans un fichier html le résultat obtenu grâce à un echo qui transforme les variables en la valeur qu'elles contiennent : En bref, zéro php dans la page elle même. (à part une include pour le menu). J'ai utilisé cette méthode au départ car on m'a déconseillé de rentrer de grands articles dans une BDD (jusqu'à 16 000 caratcères parfois)

Je souhaiterais essayer de générer ces même pages par php/sql; en rentrant l'article dans la BDD puis en l'appelant via une requête, de même pour toutes les infos sur la page. Cela me parait bien plus simple pour l'entretien du site et l'ajout de nouvelles fonctionnalités

Hors voilà, on m'a dit que des articles de 16000 caractères seraient trop lourds et feraient ramer le tout (d'autant qu'il y aura pas mal de requêtes sql sur la page entre l'affichage des images, des diverses infos etc...). Donc que dois-je faire? on m'a parlé d'utilise le type "BLOB" pour stocker de grands articles, méthode dont j'ignore tout pour l'instant, est ce que je dois me tourner vers ça?

Merci à ceux qui prendront le temps de lire ce post de me répondre

[xgamer]

le mieux pour des articles "long" c'est le type text

[f_trt]

Ta solution passe quand même par la base de données, mais ce qu'il te faut faire c'est garder ton système de cache ainsi

tu n'as pas a allez chercher ton article en base de données a chaque fois.

En gros au premier appel de l'internaute ton serveur construit la page puis la met en cache, pour l'internaute suivant c'est juste

l'include qui fonctionne.

Le gros avantage aussi c'est que ta base peut être HS pendant un certains temps sauf si tu mets des articles toutes les 5 minutes,

il restera que les recherches qui elles sont difficilement cachables et encore vu que c'est des articles que tu présentes ceux ci peuvent

alors provenir du cache.

A+

[maximettb]

Le type TEXT est en effet totalement adapté à ta situation. Je ne vois pas trop en quoi il serait déconseiller d'y mettre de gros articles, après tout, ce sont des données comme les autres. Le type BLOB pourrait également fonctionner, mais est principalement destiné aux données binaires, donc déconseillé.

L'avantage du type TEXT est également que tu peux l'indexer facilement pour être ensuite utilisé dans un éventuel moteur de recherche ( cf. index FULLTEXT ) , je ne l'ai jamais mis en application, mais ça a l'air pratique.

Après, la question du cache... Je dirais que tout dépend de la fréquentation de ton site... Mais rien n'empèche de prévoir un système de cache tout de suite ! Quant à savoir si des articles de 16000 caractères feraient ramer le site, disons que quelques dizaines de ko qui circulent dans des serveurs l'un à côté de l'autre ( quand c'est pas directement en local pour certains hébergeurs low-cost ) , je vois pas vraiment le problème, à moins bien sûr d'avoir des centaines d'accès simultanés. Ce qui fait ramer une base, c'est avant tout les jointures bien gourmandes sur des 100aines de milliers voire millions d'enregistrements.

[nyl auster]

merci pour toutes ces réponses intéressantes.

!Quant à savoir si des articles de 16000 caractères feraient ramer le site, disons que quelques dizaines de ko qui circulent dans des serveurs l'un à côté de l'autre ( quand c'est pas directement en local pour certains hébergeurs low-cost ) , je vois pas vraiment le problème, à moins bien sûr d'avoir des centaines d'accès simultanés

Effectivement si on m'avait déconseillé de mettre de grands articles pour des raisons de vitesse; mais en même temps générer toute la page de façon entièrement dynamique offre de tels avantages que je vais essayer de toute façon; ainsi je serais fixé, et ce que tu dis semble m'encourage dans cette voie. Des pages statiques sont infernales dans le cas où on veut apporter des modifications, ou ajouter un nouveau menu sur chaque page etc, ce n'est pas raisonnable et je fonce droit dans le mur à m'enteter dans cette direction j'en suis sûr...

Ta solution passe quand même par la base de données, mais ce qu'il te faut faire c'est garder ton système de cache ainsi

tu n'as pas a allez chercher ton article en base de données a chaque fois.

En gros au premier appel de l'internaute ton serveur construit la page puis la met en cache, pour l'internaute suivant c'est juste

l'include qui fonctionne.

Je vais être honnête, je suis un grand débutant en php (jai attaqué il y a un mois et demi environ), et j'ignore tout sur la méthode à suivre pour ces mises en cache, mais je vais me rensiegner dessus dès que possible voir si je suis capable de mettre ça en place ;-)

[robinsonvendredi]

A ma connaissance pour des articles longs tu as le choix entre les type BLOB, text, varchar(Max) et XML.

Selon les systèmes de bdd ces types sont un peu différents, par exemple le type text n'est pas toujours indexable, ou n'accepte pas certaines commandes SQL.

Varchar(Max) prend beaucoup de place.

Perso j'utilise soit text soit XML

[cognotte]

Wikipedia utilise il me semble le type blob pour ses articles, mais eux ils collent tout un tas d'autres trucs dans les articles (reference, date, ...)

[nyl auster]

re bonjour et merci à ceux qui m'ont répondu entre-temps. J'ai eu le temps de faire un petit essai en début de semaine en utilisant "text" sur un article de 15 000 caractères.

La page s'est affiché à une vitesse tout à fait suffisante; mais quand je vais dans php my admin dans la table qui contient l'article, ça rame énormément si je clique sur modifier...

Donc je me demande si au fur et à mesure que cette table va se remplir si ça ne va pas aller de moins en moins vite; ou bien le nombre d'aticles total contenu dans la table n'a pas d'influence sur la rapidité d'un requête?

[f_trt]

Non pas d'inquiétude. C'est d'ailleurs bizarre que ça rame dans PHPMYADMIN de toutes façon si ma mémoire est bonne

c'est un affichage de 30 enregistrements par pages donc pour continuer tes test fais en 32 ou 33 pour avoir une page complète

et tu verras. De plus tu dois pouvoir diminuer cette limite de 30 pages dans le fichier de configuration pour seulement 10 par

exemple.

A+

[nyl auster]

merci pour les conseils

EDIT :

donc si je te suis bien, même avec 150 entrées dans la table, la vitesse d'éxécution de la requête (sur ID indexé) restera inchangée ? dans quelles proportions le nombre d'entrées d'une table jouent sur la vitesse d'éxcution d'une requête mysql; et est ce que le fait d'avoir des gros articles plutôt que des petits "varchar" change quelque chose ou pas de côté?

Désolé por ces questions basiques de débutants, je voudrais être sur de ne pas me retrouver coincé dans quelques mois à cause d'un mauvais choix

Modifié 20 Avril 2007 par nyl auster

[f_trt]

Oui la vitesse de recherche n'est pas impacté ou de façon négligeable ce qu'il faut faire attention c'est a la remontée d'info ne

pas faire un select * from matable sans fixer de limites. Si tu prends des blog comme ceux basées sur DOTCLEAR il y a des sites qui

ont plusieurs milliers d'articles en base et mysql ne bronche pas pourtant tout est en base.

A lire http://www.chevrel.org/fr/optimiser/phpmysql/

[nyl auster]

merci pour tout, je vais aller lire ça très vite