MySQL est connu pour être très flexible avec la validation des données. Les conversions silencieuses ne sont pas des pratiques courantes parmi les autres SGBD. Au lieu de lancer des erreurs, MySQL lance des warnings, ce que la majorité des applications ne gèrent pas. (Est-ce que votre application fait un SHOW WARNINGS; à chaque requête?)

Néanmoins, la variable SQL_MODE permet de contrôler ce comportement. Plusieurs niveaux de validation peuvent donc être assignés, partant d’une validation quasi absente (par défaut) à une validation très stricte. Ce qui peut paraître comme une bonne affaire me parait plutôt comme une très mauvaise idée.

Le problème avec le SQL_MODE c’est que par défaut, la valeur est vide (oui oui!). Il n’y a pas de mode prédéfinie ce qui donne un comportement très souple. Plusieurs personnes ne savent pas que cette variable existe et construisent une application qui repose …

Les procédures stockées ont fait leur apparition avec MySQL 5.0. Une procédure stockée est un ensemble de plusieurs requêtes basées sur le standard sql:2003, regroupées ensemble et stockées dans la base de données. On leur attribut plusieurs avantages, notamment:

• Elles réduisent le trafic réseau: on peut exécuter plusieurs requêtes avec un seul échange entre le client et le serveur.
• Elles offrent un contrôle de sécurité: un user peut exécuter une procédure qui fait des requêtes sur une ou des tables auxquelles il n’a pas accès. Ces requêtes peuvent être en lecture ou en écriture.
• Elles assurent le respect de logiques particulières ou d’intégrité.

J’avais un cas où une application devait faire très régulièrement (jusqu’à plusieurs fois par secondes) les 4 mêmes requêtes: SELECT.. UPDATE.. SELECT.. UPDATE. En déplaçant ces 4 requêtes dans une …

J?ai fais beaucoup de tests pour m?assurer qu’une base de donnée en production sur MySQL 4 allait avoir le même comportement sur MySQL 5. Voici donc ma conclusion et les recommandations en conséquence.

La première différence que j?ai trouvé concerne les strings qu?on insère dans un champ char/varchar. Si on insère une string qui possède des espaces au début ou à la fin, MySQL4 les trim automatiquement. Ce n?est pas le cas de MySQL5. Il faut donc être spécialement attentif à ce qu?on insère et trimer tout les valeurs avant (c’est ce qu’il faudrait toujours faire de toute façon). Supposons qu?il se glisse accidentellement 2 espaces dans un champs, et qu?il y a 2 000 000 d?enregistrements dans la table. Il y aura donc 3.81 Mo de données et 3.81 Mo d?index (si le champs est indexé) pour stocker des espaces inutiles. Ça peut sembler trivial mais 3.81 Mo d?index, c?est énorme.

Une autre différence concerne …