Reprise du message précédent :

Pas forcément.
 
Prends un forum avec des sous-catégories. Trouve moi un moyen d'afficher les catégories et sous catégories (comme phpBB, pas comme ici) - c'est à dire tous les posteurs de toutes les dernières catégories - en utilisant une jointure.... à moins d'avoir un truc crade ou de débutant, c'est pas faisable

Euh... une jointure c'est utilisé la plupart du temps dans une sélection. Donc si tu as un lock à cause d'une sélection, c'est qu'il y a un petit soucis.

J'aimerais bien voir comment tu fais ...
 
edit: d'ailleurs je vois pas le problème avec une jointure mais bon.

Quand tu sélectionnes des données d'une table OK.
Mais quand tu veux prendre des données sur 2 tables à la fois, le pointeur fichier de la deuxième table doit être synchronisé avec la première table, afin de récuperer les données sur l'axe de jointure.
C'est pour ça que la table se locke avant, fait la jointure et se délocke.
Si ya du monde derrière qui veut interroger cette table, ils attendent.

esox_ch, il vaut mieux utiliser des compteurs plutot que de faire des counts,il en va de meme pour les dernier messages il vaut mieux stocker le dernier ID plutot que de selectionner un max, meme si ça dénature certains principes

 
Affiche moi en 1 requete ceci :  
 
Forum 1
 - cat1 dernier message blablabla @ telle heure par pseudo
 - cat2 " "  "               "                "
 - cat3  "                      "                 "
Forum 2
 - cat1 "              "               "           "
 - cat2 "                    "              "
Forum 3
 - cat1 "      "                    "
 

Skylight que tu bloque ta table avec une jointure ou avec un requete seule ça change quoi ? elle est tjrs bloqué non ?

Oui mais en 1 requete le pointeur de fichier n'a pas a être synchronisé avec une autre table du coup c'est très rapide, et le lock quasi-inexistant...

ptain le gain que j'ai sur l'insertion multirows
 
Je planifie une nouvelle release de DaFloodMachine ce soir.

ok je comprend mieux,
donc tu interroge deux record sets sans jointure au lieu d'un record set qui lie deux tables mais le deuxieme va devoir se réexecuter d'autant d'occurences qu'en contient le premier donc au niveau temps n'est ce pas pire?
Je vous fait pars de mon experience personnelle sur ma page d'accueil j'affiche les rubriques et leurs forums respectifs :
1ere methode 1 seule requete avec jointure très rapide
2eme methode 1requete avec une 2eme dans le while qui prend les forum de chaques rubs et c'était deux fois plus lent

 
j'ai fais ca moi tout a fait faisable
look ma page d'index :
une seule requete pour générer toute mes colonnes(hormis le nom des cat c une requete a part)
http://system-dede.com/forum/
j'ai 4 jointures et en plus des requetes additionnelles, bah 11ms de temps de generation c'est pas mal(dépend de la charge)

 
C'est le systeme que j'utilisait dans la version précédente de mon forum, et etant donné que ca me demandait des multitude de requetes pour mettre a jour les compteurs & co j'avais pensser que ce serais mieux d'enlever tout ca ..

il est de combien le gain ?

Garde dans l'esprit que sur 100 requêtes, tu as 90 SELECT et 10 INSERT ou UPDATE...

Skylight : soit tu as des champs pour enregistrer l'id de la derniere reponse et c'est déjà fini, soit tu fais des sous requetes ...
 
Je serais curieux de voir ta méthode tiens ...

mauvais DBMS, changer DBMS

esox_ch, oui ça demande de la gestion de gerer des totaux et des dernier ID (verification et decrementation lors des suppression etc) mais le count tourne bien car ton forum dois être assez petit.Imagine un count des tes messages pour CHAQUES sujet dans une table de post aussi grosse que celle de ce forum ...

 
Excuse moi je comprend pas trop en quoi ca change qqch?
 

 
J'ai encore un peu de lacunes (enfin pas mal de lacunes) en SQL et optimisation ... je penssais que quoiqu'on mette dans la requette, 1 requette sera toujours + rapide que 2 requettes ...

 
En 1 requete tu m'affiche tout ca toi ?
 
Forum 1  
 - cat1 dernier message blablabla @ telle heure par pseudo  
 - cat2 " "  "               "                "  
 - cat3  "                      "                 "  
Forum 2  
 - cat1 "              "               "           "  
 - cat2 "                    "              "  
Forum 3  
 - cat1 "      "                    "  
 
 
 
 

 
Si oui, j'aimerai bien voir la gueule de la query ...
 
sachant que moi, pour chaque catégorie (pas forum), je stocke en plus de l'id du dernier message, le pseudo, l'heure, le topic ...
 
 
mais affiche tout un index en 1 requete ...

 
Il me semble avoir lu cela sur la doc de MySQL.

 
En termes de vitesse et de charge, les SELECT (en règle générale ) sont moins lourds et + rapides que les UPDATES ou INSERT.

Je viens de regarder la doc, j'ai pas trouvé de trucs parlant d'un lock quelconque ou d'un probleme de rapidité avec des jointures ...
 
Voila une version toute conne si l'id de la derniere reponse est enregistrée pour chaque cat :
SELECT nom_forum,nom_cat,rep_id,membre_id,pseudo,... FROM forum
LEFT JOIN cat ON cat_forum_id=forum_id
LEFT JOIN reponses ON rep_id=cat_derniere_rep_id
LEFT JOIN membre ON membre_id=rep_membre_id

je refais un bench ce soir et je vous dis ça
j'avais 40 secondes comme temps de référence chez moi pour la version 2 (et 100 secondes pour la v1). La version 2.1 met 25 secondes sur ma machine boulot (plus lente) sur une DB hostée sur une autre machine.

C'est possible qu'ils gère cela comme ça, je n'ai pas lu entièrement leur doc. Mais si c'est le cas, c'est la preuve d'une mauvaise conception de leur gestion des lock. Un lock ne devrait être mis sur une table que lors de la modification de celle-ci, et encore. Dans la plupart des cas, un DBMS doit pouvoir s'en sortir avec les transactions et les write-ahead.

 
To decide whether you want to use a storage engine with row-level locking, you will want to look at what your application does and what mix of select and update statements it uses. For example, most Web applications do lots of selects, very few deletes, updates based mainly on key values, and inserts into some specific tables. The base MySQL MyISAM setup is very well tuned for this.  
 
Table locking in MySQL is deadlock-free for storage engines that use table-level locking. Deadlock avoidance is managed by always requesting all needed locks at once at the beginning of a query and always locking the tables in the same order.  
 
The table-locking method MySQL uses for WRITE locks works as follows:  
 
If there are no locks on the table, put a write lock on it.  
Otherwise, put the lock request in the write lock queue.  
The table-locking method MySQL uses for READ locks works as follows:  
 
If there are no write locks on the table, put a read lock on it.  
Otherwise, put the lock request in the read lock queue.  
When a lock is released, the lock is made available to the threads in the write lock queue, then to the threads in the read lock queue.  
 
This means that if you have many updates for a table, SELECT statements will wait until there are no more updates.  
 
http://dev.mysql.com/doc/mysql/en/ [...] cking.html

 
Scusez moi, je me permets de upper ma question concernant un bon hébergeur gratuit (si possible) gérant le php/mysql, mon serveur perso ne pouvant pas rester allumé 24/24 (problème de chaleur, des fois que des températures estivales arrivent )
 
merci

Derniere question ... J'ai donc cru comprendre que la fonction count() est a bannir de mes requettes des que le nombre d'enregistrement en question risque d'etre élevé?

Quelle horreur

pour les hébergements, c'est ici: http://forum.hardware.fr/forum2.ph [...] 0462&cat=4

 
ok merci bien j'avais pas pensé à chercher là bas.
 
Je publie la v0.1 de mon forum ce soir je pense

je publie bientot la v0.0001 béta de mon forum

vu le numéro de version, je te conseillerais "alpha" plutôt que "beta"

et oui l'informatique c'est des 0 et des 1
 
 
 

 
Quoi que dans certains cas on se demande si c'est pas 1/2
 
 
Je bosse actuellement sur la suppression de sujets (des gros genre 10000 réponses), et la mise à jour de certaines informations me posent problèmes. Si je supprime un sujet des 10 000 messages, un total de 500 utilisateurs ont posté dans ce sujet, il faut mettre à jour le nombre de messages posté par chaque utilisateur.
 
 
Comment faites vous pour mettre à jour le nombre de réponses d'un utilisateurs sachant que l'on souhaite éviter un balayage complet de la base avec un SELECT COUNT pour chaques users (pour des raison des perfs....) ?

langage objet
si tu as une methode supprimer message tu l'appelle a chaques message trouvé et cette methode se charge daller decrementer le user.
en gros fais une procedure supprimer message qui fait tout pour un message et appelle la dans ton record set lors de la suppression d'un sujet.

je fais un select recuperant les id des posteurs et le nombre de post de chacun dans le sujet en question
apres pour chaque ligne de mon résultat de requete j'effectue un update en soustrayant au membre le nombre de post qu'il avait dans le topic
 
c'est tout

ma methode fait beaucoup moins de requetes
 

Il faut aussi vérifier si ton post que tu supprimes n'est pas le dernier message vers lequel pointe tous les forums (genre afficher un lien vers un dernier message qui n'est plus là...) et auquel cas recalculuer le plus récent message pour ce forum ... J'espere que ta méthode super light fais tout ça aussi spike

biensur, mais j'ai juste dis comment je faisais la decrementation du nb de post par user la

Pour savoir si une reponse est la derniere postée sur un sujet (et sur un forum) il y a un moyen a part de faire une colonne "is_last" qu'on updatera chaque fois que qqn poste?

seul problème. il faut enlever le is_last à l'ancien dernier.
 
à mon avec un index sur la date et rulez