Re: Last ID

[Julien Stuby]

Je recolle le dernier message pour que le suivit soit cohérent :
Dernier message du 26 Décembre 2008 :


Jean Molliné Wrote:
-------------------------------------------------------
> ... pourrions nous modifier les requêtes insert
> et update d'une table cible pour post-enregistrer
> la valeur du nouveau ID sans appeler explicitement
> la procédure stockée
>
> Je ne suis pas certain de bien saisir l'intérêt
> de la chose. En utilisant un trigger, on appelle
> pas explicitement la procédure stockée, c'est le
> trigger qui va s'en charger en détectant
> l'insertion ou la mise à jour. Je ne suis pas un
> spécialiste en la matière non plus, mais l'idée
> générale reste la même et on tente de gagner en
> performances si j'ai bien suivi. Or à mon sens,
> ce n'est pas là qu'on fera des gains
> significatifs : Ce qu'il faudrait étudier
> soigneusement, ce sont les choix des index par
> exemple. L'utilisation d'un EXPLAIN sur les
> requêtes peut s'avérer une aide précieuse en la
> matière.

Triggers c'est du bon :) donc on arrive récupère le lastID assez facilement, reste le problème de la tête de lecture ! En faite pour faire un tris elle parcours l'ensemble des données, puis retourne le tris.

Prennons l'exemple :

Select * from lines;

--> il n'y pas de tris, les enregistrements sont retourné selon le sens l'empilage, la tête de lecture parcours entièrement la table

Select * from lines limit 10

--> il n'y pas de tris, les enregistrements sont retourné selon le sens l'empilage, la tête de lecture parcours les 10 premiers enregistrements

Select * from lines where ID>2000

--> il y a un tris sur la colonne ID (du plus petit vers le plus grands), la tête de lecture parcours l'ensemble des enregistrements, les enregistrements sont retournés selon l'ordre du tris.

Donc la solution la plus rapide c'est le limit car il y a pas de tris et la tête de lecture ne parcours pas l'ensemble des enregistrements ( je dis cela selon mes testes, si on pourrait ensemble se pencher dessus ? ). Le plus grand problème avec le limit sans tris, c'est qu'il lit selon l'ordre d'empilage, du bas vers le haut ! Si il lisait du haut vers le bas, il serait simple de retourner les 10 derniers enregistrements insérés dans une table (je parle ici d'empilage simple, sans modification et suppression d'élément dans la table -> ref. Huu Da Tran :) ) -> Il serait simple de retourner les données à vitesse grand V sans traitement superflu.

Si bien même tout les données étaient indexées et que le traitement se faisait entièrement en mémoire, cela n'enlèverait en rien les traitements superflu effectués sur la table.

Si quelqu'un voit quelque chose ?

:)