Reprise du message précédent :

Pas si c'est un index simple ordonné normalement (bTree, toussa toussa)

 
Oui je suis d'accord avec toi, mais lorsque tu fais des suppressions [EDIT] : ou modifications,[/EDIT] ta table n'est plus ordonnée, donc t'es obligé de faire un ALTER TABLE ta_table ORDER BY champ [DESC|ASC]
 
et donc ça bouffe à mort de faire ça

Nan justement ... Je me suis battu jusqu'au sang avec un forumeur de ce topic car je pensais la même chose
 
Quelques tests plus tard, il s'avère en réalité que si tu as une table, avec comme enregistrements :
 
1
2
3
4
 
Tu supprimes 3, tu as :
 
1
2
4
 
Tu ajoutes un nouvel enregistrement :
 
1
2
4
5
 
Et pas :
 
1
2
5
4
 
 
J'espère qu'on parle de la même chose
 
PS : Que personne ne me dise le contraire, j'ai débattu sur je-sais-pas-combien de posts là-dessus, on m'a mis la grosse patée, alors que personne vienne m'annoncer que j'avais finalement raison

Oui on parle bien de la même chose
 
Seulement tu as surement fait des tests ordonnés en "ASC"
 
Prenons une table de test (même sans suppressions/ajouts tu vas voir que ça foire). Bref une table avec un seul champ "id" sans autoincrément.
 
Tu insères une dizaine d'enregistrements avec des id qui se suivent (perso j'en ai mis 10). Ensuite tu fais un ALTER TABLE test ORDER BY id DESC.
 
Tu affiches ta table (SELECT id FROM test)
 
ça va t'afficher tous les id ordonnés du plus grand au plus petit.
 
Maintenant, insères un enregistrement ayant une valeur supérieure (enfin peu importe mais c'est pour que tu vois où est placé l'enregistrement ensuite) bref moi j'ai pris 11. Ensuite tu refais ton SELECT id FROM table et tu vas voir que le 11 ne sera pas en haut, mais en bas...
 
T'es donc oligé de refaire un ALTER TABLE test ORDER BY id DESC, ça bouffe des ressources, et donc tu imagines bien que sur un UPDATE/DELETE c'est pareil

on parle de l'index, pas du datafile.
quand tu fais un select sans where, ca n'utilise pas du tout le fichier d'index

Avec un index ça reste ordonné ?

 
Hmmm ... J'ai sûrement fait le test avec un index auto-increment

L'exemple était ultra-simplifié, l'intérêt c'était l'index ordonné, donc j'avais bien un WHERE

voilà, dès que je fais le test avec un index c'est ordonné en ce qui me concerne, je vais tenter de désordonner ça, ou de trouver des infos

Oui, si MySQL utilise un "using index" comme méthode de rapatriement.

 
heu, on parlait pas des indexes là ??? parce que ça n'a rien à voir avec les indexes ça.
 
l'allocation des rows c'est le problèlme du moteur et on cosidère toujours que c'est en O(1)

Je croyais qu'on parlait des lignes ordonnées ou non en cas de suppressions/updates.
 
Je file m'acheter des lunettes ^^

très interessant les résultats que je viens d'avoir
 
SELECT numreponse FROM threadhardwarefr13 WHERE numeropost='11183' LIMIT 561000,30;
30 rows in set (0.53 sec)
 
SELECT * FROM threadhardwarefr13 WHERE numeropost='11183' LIMIT 561000,30;
30 rows in set (50.42 sec)
 
 
Seule différence : la première requète fait un USING INDEX parce que tout est dans l'index file.

bah les lignes sont dans le désordre sur le disque (sauf truc spécial dont j'ai oublié le nom et rarement utilisé)
 
Joce parlait de laisser des trous dans l'arbre je crois, virer la ligne de la table, mais pas réorganiser les indexes.

(note :  
 
SELECT numreponse FROM threadhardwarefr13 WHERE numeropost='11183' ORDER BY numreponse LIMIT 561000,30;
 
30 rows in set (0.71 sec))

 
Bah c'est intuitif nan ? Si les données sont dans l'index, MySQL parse seulement l'index ?

T'as une table par catégorie ?

Je confirme pour Josaÿ
 
EDIT : Histoire de WHERE, I/O disque, toussa toussa

bon j'ai compris : cet abruti rapatrie vraiment tous les résultats, et seulement en suite applique la clause LIMIT

Oui, c'est ce que je disais plus haut

joce > tu peux expliquer ce qu'est l'index file ? et plus précisément ton raisonnement stp ?

Nan mais ce que je veux dire qu'à la limite, t'as interet à faire la requète en deux fois

 
T'utilises pas de LIMIT pour ton forum ?

Me ?
 
Si oui, j'ai une solution relativement bancale pour l'affichage des messages ds un tomic (Avec un IdInsideTopic) donc sans LIMIT
Pour l'affichage des tomics, pas de solution particulière, donc LIMIT
 
Cet été, tout le code va valser pour une nouvelle version codée à plusieurs, ca va roxxer

Ba  
 
CREATE TEMPORARY TABLE pouet SELECT numreponse FROM threadhardwarefr13 WHERE numeropost='11183' ORDER BY numreponse LIMIT 561000,30;
SELECT * FROM pouet LEFT JOIN threadhardwarefr13 USING (numreponse) ORDER BY numreponse ASC;
 
=> 0.57s + 0.01s
 
rulez

 
Oki

D'ailleurs, me tate pour passer la future version en open-source

ça n'a pas l'air de trop ramer, dommage qu'on ait pas les temps de génération histoire de se faire une idée.

 
J'aime trop pas

 
Je te l'ai dis sur le topic serveur@home mais je te le repete, l'effet sur les bordure de tes forums est superbe. J'ai pas reussi a le reproduire en CSS

joce > tu utilises quoi comme régie de pub ?

Mais c'est effectivement codé à la barbare

 
Quel effet ?

L'ombre sous les tables je pense...

Oui l'ombre sous les tables

c'est une image

http://deuxfleurs.org/stuff/tableshade.html Ok le markup est pas génial mais bon, c'est faisable quoi ...

il a pas pompé cette option sur phpbb ?

Il y a pas moyen de faire plus simple ?

 
Surement,  
tu peut virer un div si tu limite un peu la largeur de tes blocs en faisant une sliding window par exemple...
 
Sinon vu la faible utilité de l'ombre portée, tu peut accepter qu'elle ne soit visible que pour les gens qui ont Javascript activé, et faire la décoration du bloc sur tout les elem qui ont une certaine classe. Tu gagnera sur ton markup mais tu allourdiras l'effort du client

c'est quoi comme forum? j'ai cherché, j'ai pas trouvé de nom. c'est du fait maison ?