13/10/2005 @ 21:26:47: MySQL - MySQL 5 sera en production en novembre!
MySQL AB aimerait que cela en soit ainsi en tout cas, ils voudraient pouvoir proposer MySQL 5, une nouvelle évolution majeure dans le cycle de MySQL, pour le mois de novembre en production!
Au niveau des fonctionnalités apportées, on parle (enfin) de triggers, de vues et de procédures stockées. Avec ces nouvelles fonctionnalités, tant attendues par de nombreux développeurs, MySQL pourrait finir par entrer un peu plus dans le marché des bases de données entreprises.
Bon, il ne faut pas non plus trop se glorifier, MySQL, avec sa version 5, vient à peine d'arriver à proposer toutes les fonctionnalités comme le propose les autres acteurs majeurs depuis des années, mais avec le temps, le petit DBMS remonte la pente et rattrape son retard. Allons, ne gâchons pas notre plaisir, vive l'évolution et vive MySQL 5 tout de même!
Oui, il rattrape son "retard" mais bon il serait bien de préciser qu'il fait cela en semi/open-source..
cela dit postgres à fait ca en moins de temps aussi... mais j'accroche pas à postgres.. faudra que je m'y mette sérieusement..
de plus le test que j'avais réalisé avec le meme dump sql en postgres et mysql un simple "select id, toto, toto from tata where titi='ok' order by titi limit 400,600 asc" c'était plus lent en postgres..
de plus le test que j'avais réalisé avec le meme dump sql en postgres et mysql un simple "select id, toto, toto from tata where titi='ok' order by titi limit 400,600 asc" c'était plus lent en postgres..
Evidemment, quand on est pas foutu de faire des query correct...
C'est quoi le problème de la requête ici en l'occurence ?
Qu'il fait un where titi = '...' et un order sur ce même titi (ce qui est bien sûr inutile dans ce cas) ?
Si c'est ça à mon avis c'est rien, il a simplement voulu mettre des noms de champs au hasard je pense.
Dernière édition: 14/10/2005 @ 10:42:29
bah oui, mais d'un part le order n'a aucune obligation de donner les mêmes résultats d'une requete a l'autre (cf spec SQL), d'autre part utiliser une clause limit avec offset est l'une des erreurs les plus basiques qu'un programmeur doit apprendre a éviter.
Je ne suis pas spécialiste BD/SQL alors si tu pouvais expliquer en 2 mots pourquoi c'est une erreur, je t'en serais très reconnaissant
Pour le order je ne comprends pas bien non plus : un classement sur les mêmes données sera quand même toujours identique ?
gizmo> Hum, quand t'as une table de 1000 entrées et que tu affiches le tout par page de 20, je vois plus vraiment d'autre solution.
Bien sûr, on peut se la faire en ajoutant un id qui se suit réellement pour permettre de limiter sur l'id, mais c'est pas super jouable qd t'as la possibilité d'avoir beaucoup de suppression, ca pourrait prendre plusieurs secondes pour une simple suppresion...
Donc bon, je préfère encore ce bon vieux limit
Heureusement que Joce n'utilise pas de limit
Bon, commençons par le ORDER.
A partir du moment où la selection se fait sur un critère d'égalité strict sur le champ qui ser a ordonnance, l'ordre est trivial pour ce champ. Par contre, il faut encore résoudre la question du tri scondaire, tertiaire, etc... Or ici, rien n'est précisé, et c'est au moteur de prendre donc une décision, qui n'est peut-être pas ce que l'utilisateur attend. Il pourrait très bien se baser sur un oid interne, comme il pourrait se baser sur un calcul d'un index ou les autres champs dans la requete. Aussi, on n'a pas de garantie que le résultat retourné sera toujours le même dans le même ordre, sauf si le DBMS le précise dans sa doc, et ne décide pas de modifier cela d'une version à l'autre.
Pour la question du LIMIT.
Tout d'abord, le LIMIT n'est pas standard, il faut donc limiter, c'est le cas de le dire, son utilisation. Ensuite, comment fonctionne un limite sur une requète avec un critère de sélection (donc pas un SELECT * FROM table LIMIT 10)? Il exécute la requète, puis, si le DBMS est bon, instancie un curseur (sinon il charge tout en mémoire) et va tout d'abord jeter un a un les x premiers enregistrement correspondant à l'offset demandé (donc ici 400 lignes qui sont instanciée puis jetées). Ceci constitue un ralentissement au moment de retourner les résultats, mais également une augmentation de l'utilisation de la mémoire. En outre, vu que la sélection n'est pas suffisament restrictive pour sortir directement les 200 bons enregistrement, les opérations internes seront également plus lourdes, surtout dans le cas de jointures (ce qui n'est heuresement pas le cas dans l'exemple). Il est donc tout bénef de changer son critère de sélection, quite a rajouter une colonne d'information. Pour l'exemple de l'Id inidqué par zion, une solution simple serait d'indiquer l'id du dernier enregistrement de la plage précédente (Ce n'est pas safe dans tous les cas, je sais, c'est une idée au vol).
Voila, j'espère que j'ai été clair.
gizmo> Je suis d'accord sur le fait qu'il sélectionne tout puis fait sa sélection, mais, je me vois mal rajouter un id géré par moi même (bonjour la merde en cas de delete, joce en sait qqchose), pour tout ce qui est affiché sous forme de pages.
Rien que pour ce site, j'ai plus d'une centaine de tables (
), dont une bonne partie ou j'y utilise des limit. Bien sûr je pourrais tenter de restreindre largement les elements du query en y rajoutant, comme dans ton idée, un autre id, mais cela ne fera une restriction que d'un côté et je ne peux pas m'assurer en faisant id du dernier de la page précédente + 1000 que j'aurai par exemple les 20 qu'il me faut dans une catégorie d'un forum.
Pour ma part je sais que c'est pas super performant, mais la solution d'un deuxième id géré par mes petites mains sur toutes ces tables, ca me fait froid dans le dos quand je vois le temps que ca me prendrait pour le gérer
Ca c'est bien le problème des informaticiens de pure souche.. toujours rajouter une couche..
perso je m'en fou, c'était un exemple pour illustrer mon expérience que postgres était plus lent dans ce type d'exemple..
/me heureux de pas être un geek
