Editer un commentaire - Informaticien.be

Publié le: 13/10/2005 @ 21:26:47: Par zion Dans "MySQL"

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!

Editer un commentaire

Sujet
Texte	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.