Voilà , c'est fait la première rencontre du MySQL Belgian User group s'est tenue dans les bureaux de X-TEND à Kontich. Ce n'était pas un hasard, X-tend est partenaire "MySQL Network" pour la Belgique.

14 personnes étaient présentes pour écouter Geert Vanderkelen, un compatriote, qui travaille en Allemagne pour MySQL.

Bon d'accord sur 14 il y avait 6,5 employés X-Tend mais ce n'était pas du remplissage.

Pour cette première session, la réunion ne s'est pas axée sur un échange mais par une présentation générale de MySQL et de des nouveautés.

L'annonce disait que la rencontre se ferait en anglais français néerlandais et allemand. Ouf il n'ya pas eu d'allemand. Par contre ce qu'il n'avaient pas précisé c'est que les 3 langues restantes seraient utilisée dans les même phrase. Ce fut assez comique. L'anglais restant majoritaire pour la présentation.

Personnellement je n'ai pas appris grand chose, sauf les nouveautés de MySQL 5.1.

• le moteur de stockage "MERGE" est déjà condamné à disparaître. . . parce que replacé par le "partitioning" qui permettra d'obtenir le même fonctionnement mais sans plus être limité à des table filles "MyIsam" tous les (à confirmer, si pas remplacer par "plusieurs") moteurs de stockage.
• mysql_upgrade, mysqlslap, que je vais m'empresser d'aller découvrir
• mysql log table : Les logs de mysql seront en table donc accessible via des requêtes SQL. Ce qui apporte un flot d'avantage comme l'apparition en 5.0 de INFORMATION_SCHEMA pour pouvoir se passer des SHOW (et sur tout de leurs résultat à parser)
• l'EVENT SCHEDULER qui m'intéresse particulièrement. En gros c'est un cron interne à MySql. Il sera donc possible de "programmer dans le temps" l'éxécution d'une requete ou d'une routine.
• les fonctions XML. mais bon ca c'est comme les subroutines, ca ne sert à rien c'est MySQL qui répond aux demande payantes et pressantes. J'espère qu'on pourra désactiver pour gain de perf. Après rediscussion sur le sujet, l'intérêt de ces fonctions XML est de pouvoir descendre dans la DB de plus en plus de code métier. Je suis pas chaud, c'est pas le boulot de MySQL. Mais ca peut avoir sa valeur quand on veut assurer une intégrité logistique sur un système d'information qui serait attaqué par plusieurs applications.

Lire la suite...

CREATE TABLE `users1` (
`name` varchar(10) default NULL,
`birthday` date default NULL
);

CREATE TABLE `users2` (
`name` varchar(10) default NULL,
`birthday` date default NULL
);

SELECT COUNT(*) FROM users1;
+----------+
| COUNT(*) |
+----------+
| 15       |
+----------+

SELECT COUNT(*) FROM users2;
+----------+
| COUNT(*) |
+----------+
| 12       |
+----------+

SELECT * FROM users1 
UNION 
SELECT * FROM users2;

• exactement 27
• au minimum 12
• au minimum 15
• entre 1 et 27
• Zero ou plus

Voir la réponse ▼

SELECT * FROM theTable;

+----+----------+
| id | data     |
+----+----------+
|  1 | milieu   |
|  2 | premier  |
|  3 | showLast |
+----+----------+

Maintenant trions sur `data`.

SELECT * FROM theTable ORDER BY data;

+----+----------+
| id | data     |
+----+----------+
|  3 | showLast |
|  1 | milieu   |
|  2 | premier  |
+----+----------+

hum??? Peut-être sur le serveur n'a pas compris.

SELECT * FROM theTable ORDER BY data ASC;

+----+----------+
| id | data     |
+----+----------+
|  3 | showLast |
|  1 | milieu   |
|  2 | premier  |
+----+----------+

Que se passe-t-il ? Il assure ne pas avoir switché vers une quelquonque collation inversée.

Voir la réponse ▼

SHOW CREATE TABLE theTable;

CREATE TABLE `thetable` (
  `id` int(11),
  `data` enum('showLast','milieu','premier')
)

MySQL 5.1.12 ne supporte plus DBD.

Il faut faire une migration AVANT de mettre à jour.

Source blog de Peter Laursen

SELECT CONCAT('a','foo',null,'bar');

donne NULL parce que c'est son comportement normal.

Si toutefois on désire avoir un retour avec les NULL considérés comme chaînes vides une autre fonction viendra à notre secours.

Lire la suite...