Reprise du message précédent :
Pour comptabiliser le nombre de visites quel est selon vous le plus rapide?
- une table avec une seule ligne que j'UPDATE
- un fichier sur le disque

Micro optimisation, tu t'en fout, fait au plus facilement maintenable => DB

Va pour la DB

que veut tu dire par "nombre de visites" ? le nb vue du topic ?

Non par exemple le nombre total de visites du site à chaque fois qu'une page est affichée.
 
Sinon une autre question niveau optimisation moins micro que ma précédente:  
 
Imaginons que j'ai 3 tables:
 
User
RoleManagement(user_id, role_id)
Role
 
Qu'est-ce qui est plus performant?
- faire une jointure dans la BDD
- faire sauter la table RoleManagement, et sauver les associations dans un champs roles de la table User (exemple: 3:2_6:5_4:5) et décoder ce champs à la volé de manière à reconstituer les roles du user.
 
Quelqu'un a déjà tenté l'expérience? Pour ma part ce serait un match entre Ruby et PostgreSQL. Y'aurait-il un écart non négligeable dans un sens comme dans l'autre?
 
EDIT: je pense que pour construire les roles d'un User, ça passerait, mais pour construire les roles de plusieurs users, la jointure serait largement devant ?

ca c'est vraiment inutile, il existe pleins de services de stats sur internet, dont le plus connu xiti.
 

Xiti s'pourri C'est lent et moche
 
Mint FTW

Tu normalises => jointure
Si tu veux absolument dénormaliser, il faut que ce soit réellement motivé par un contexte très spécifique. Pas par un "j'aimerais que ça aille vite là, comme sur toutes mes requetes quoi !"

moche?    
 
puis lent ?    
 

Oui

non mais j'attendais des arguments    
 
 
 

pour le moche, t'es pas obligé d'afficher l'image.
pour le lent, si t'appelles le marqueur en javascript, tu bloques pas ta page, magique nan ?

C'est lent et c'est moche, j'vois pas ce que tu veux de plus

Wow, avec des workarounds dégueux t'arrives à le faire marcher moins mal, I'm so impressed

mais tu parle de quoi? du petit logo en bas de page? ou bien de l'interface ou tu te connecte pour voir tes stats?
 
Tu sais, c'est un outil (et gratuit en plus), suffit qu'il soit fonctionnel, la beauté on s'en fou
Et pour la vitesse, je le met sur tous mes sites et ca rame pas

De l'ensemble.

50% du temps, quand un site rame ou n'en finit pas de se charger c'est xiti qui merde

nope

 
Tu peut le faire sans modifier le code à insérer qu'ils fournissent, sinon, c'est autorisé de faire la modif ?
(Avec les trucs google par ex. on peut pas, c'est un poil chiantounet des fois )

C'est possible sans problème, c'est même xiti qui fournit le code Javascript en exemple, je l'ai fait il y a 5 ans sur le site corp de la plus grosse boite française (site en .com) (je vous laisser chercher et regarder le code source )

Vous avez des success / horror stories à partager concernant l'utilisation de sqlite? Y'a quasiment rien sur tout le forum.
 
EDIT: sqlite est out quand il s'agit d'un site où un moteur de recherche est un élément essentiel.

SQLite est surtout pas prévue pour être utilisé dans des environnements avec pleins d'accès concurrents en écriture, elle pose un verrou sur toute la base à chaque écriture.
Après, c'est une base destinée à être embarquée dans des applications plutôt, c'est possible de l'utiliser pour des sites web mais faut pas lui en demander autant non plus qu'une base de données en mode client/serveur.
 
Sinon, pourquoi c'est pas adaptée particulièrement pour des moteurs de recherche ?

"avec pleins d'accès concurrents en écriture" concrètement ça se chiffre comment? J'ai lu dans un bouquin que Sqlite était génial et que ça pouvait convenir à site où environ 300 visiteurs se balladaient sur le site, ce qui représente plusieurs millions de page views par mois. Maintenant c'est peut-être que des SELECT ou carrément de la mise en cache des pages vues. Je ne sais pas combien d'INSERT ou autre ça représente ça n'est pas précisé. Tu l'as déjà tenté en production?
 
Le problème de sqlite, c'est que j'arrive pas à trouver des expériences réelles. Tout ce que de trouve c'est de la théorie.
 
Pour le moteur de recherche, c'est que par exemple Sphinx ne peut pas être utilisé avec sqlite à moins d'utiliser une version patchée non officielle, donc toujours un peu risqué.

C'est pas complètement vrai.

Elle n'est absolument pas "destinée à être embarquée", même si "être simple à embarquer" fait partie de ses buts

Y'a CouchDB qui me botte aussi, par contre la manière dont les données sont stockées est un peu particulière. Générer des rapports / statistiques peut être un poil limité. apparemment pas.

Regardes du coté de Tokyo Cabinet, si les DBs non relationnelles t'intéressent, d'après les posts que j'ai pu voir ça a l'air d'être une des rares qui soit mature et avec des perfs correctes actuellement.
 
http://www.igvita.com/2009/02/13/t [...] lue-store/
http://www.scribd.com/doc/12016121 [...] esentation
http://tokyocabinet.sourceforge.ne [...] /#tutorial

Je connaissais pas TC. Je regarde. Merci

J'ai utilisé quelques fois sqlite, dans des ptits projets web en python et comme stockage sur des trucs desktop en C++, dans les 2 cas ça a été très satisfaisant. Le seul point noir c'est le manque de foreign key, on peut compenser avec les triggers (y'a même des outils exprès), mais c'est pas aussi pratique qu'un support direct. À part ça, pas de mauvaises suprises dans le support SQL lui même.

Pour les perfs, j'ai jamais eu l'occasion de tester ça avec de nombreux clients par contre.

Merci 0x90

Je l'avais utilisé en production sur un client lourd, qui avait une tâche de fond qui mettait à juor les données de la base à partir d'un serveur (un système de synchronisation automatique).
Je m'en suis occupé qu'au début du logiciel, après j'étais passé sur la partie serveur. Mais j'avais suivi un peu le travail de l'équipe cliente, et ils s'étaient un peu mordu les doigts, à cause du thread qui faisait la synchro d'un coté, et du thread "principal" qui essayait d'écrire dans la base au même moment suivant ce que faisait l'utilisateur.
Aux dernières nouvelles que j'avais avant que je change de boite, c'est que tout les accès en écriture étaient sérialisés par un verrou partagé entre les threads, et qu'on limitait au maximum les grosses (longues) écritures pour éviter de bloquer complètement l'utilisateur
À l'époque, j'avais jeté un oeil dans quelques logiciels qui l'utilisaient et j'avais souvent vu qu'un thread était dédié à la communication avec la base et qu'il sérialisait aussi plus ou moins les écritures (elles passaient toute par ce thread). Par contre, ça date un peu, c'était en 2006-2007 je crois, il y a du avoir pas mal de progrès fait depuis.

Pour les applications webs, j'ai pas d'expérience à remonter, mais j'imagine que c'est plus facilement jouable car la quantité de trucs à écrire à chaque fois est pas trop grosse (en règle générale). Du coup, ça bloque pas trop tout le monde, même si il y a du trafic (au pire, tu joues un peu sur la valeur du timeout d'attente d'obtention du verrou).

C'est une vision simplifiée effectivement, mais en pratique, c'est un peu ce qu'on observe.

Si on transactionne les écritures correctement, il y a apparemment relativement peu de contention, en tout cas initialement (après effectivement si tu tapes 15m pages vues par mois dont 10% d'écritures, tu risques de rencontrer des problèmes)

Ca consiste en quoi déjà la prévention contre les attaques par code concaténé dans une image? Il me semble que le code du forum avait une faille à une époque mais je ne retrouve pas le thread. Il suffit de vérifier que le content-type du fichier soit bien image/jpeg ou png? Vérifier l'extension?

Le code ne vérifiait pas (par exemple avec exif) que l'image était bien une image. Il dupait justement le serveur en collant un fichier flash avec une extension d'image.

je pense que c'est plus simple, joce verifiait seulement l'extension, pas le contenu  
 
par exemple script_flash.jpg, ca passait  
 
 
Ensuite, il suffisait de l'appeler de l'exterieur, et comme il est hebergé sur le serveur, il peut executer des requetes interdite depuis l'exterieur (recuperer cookie notamment).
 
 

Niveau usability, quelqu'un a déjà tenté un tag based forum VS un category based? Le truc c'est que certains messages pourraient aller dans 2 catégories (donc les tags facilitent le cross post), mais j'ai peur que ça devienne le boxon. Vous en pensez quoi? Un mix des 2 ou juste les catégories? Je peux forcer qu'au moins un tag officiel soit inséré et laisser l'utilisateur en rajouter 2-3 ça peut être cool?

drapal une vrai mine d'or ici !!  
je suis un petit dev web : voici un de mes sites http://www.prixjeuxvideo.com (loiiiiiiiiin d'être fini)

Est-ce que vous avez 2 tables séparées pour le 1er post d'un topic et ses réponses? Ou bien c'est tout dans la même table avec un parent_post_id sur les réponses uniquement? Vous considérez que c'est 2 objets séparés?

Pour moi le premier message est un message, donc table messages, indépendante de la table topics.

idem, surtout que bien souvent, un sujet possède bcp plus d'informations qu'une réponse :
Icone du topic, statut du topic, date & heure de la derniere réponse, le nombre de lecture, la catégorie du topic etc...
 
Alors qu'une réponse possède quand meme bcp moins de champs

Désolé j'ai pas utilisé le bon vocabulaire. Donc il faudrait les tables et grosso modo les colonnes suivantes:
 
Category (id, title, ...)
Topic (id, category_id, user_id, title, icon, content, messages_count, last_message_at, ...)
Message (id, topic_id, user_id, content)

Comment vous gérez les sujet lu / non lu?
 
J'ai pensé créer une table de jointure:
Aware(user_id, topic_id, last_time_read_at) mise à jour à chaque fois que le user lit un topic. C'est un peu lourd mais bon y'a pas trop le choix.
 
Ensuite faire un LEFT JOIN awares lorsque j'affiche ma liste de topics, et si jamais awares.last_time_read < topics.last_message_at ça veut dire qu'il faut afficher une icône 'nouveau message depuis votre dernière visite'. J'ai bon?
 
Et niveau maintenance? La table va devenir gigantesque? On s'en fout? Il faudra la purger de temps en temps? Vous créeriez un compound index sur user_id et topic_id?
 
Globalement, si on veut coder un forum avec un minimum de fonctionnalités pour simplifier la vie des visiteurs on est obligé de taper fort sur la base de donnée Et c'est là que je me rends compte pourquoi un forum phpbb est si lourd et crado.
 
A part ça mon petit forum écrit en Ruby on Rails avance tranquillement
 
EDIT: et effectivement séparer Topic et Message en 2 tables est la bonne solution  

Pour gérer le design j'ai tenté un full-CSS, mais en fait je crois qu'une bonne vieille <table> convient mieux. Vous êtes plutôt quoi?