Quoi qu’on en pense, les views dans MySQL sont très utiles dans certaines circonstances. Cependant, on peut silencieusement les briser sans s’en rendre compte en modifiant la structure d’une table qui l’utilise. C’est malheureux, mais pas dramatique puisqu’aucune donnée n’est perdue…

Faux !

Si vous utilisez mysqldump pour faire vos backups, il est très dangereux de briser une view.

CREATE TABLE a (a int);
CREATE TABLE b (b int);
CREATE VIEW abview AS SELECT a,b FROM a INNER JOIN b ON a.a = b.b;

Le temps passe et on oublie qu’on a créé une view…

ALTER TABLE a CHANGE a a_field int;

Tout continue de bien fonctionner jusqu’au moment où on fait nos backups..

patlaf@noidea:~$ mysqldump -uroot -p --all-databases > /dev/null
Enter password:
mysqldump: Couldn't execute 'show create table `abview`': View 'test.abview' references
invalid table(s) or …

Au boulot, je suis régulièrement confronté à ce que les développeurs croient être le mieux pour une application, versus ce que je crois qui est le mieux pour le serveur de base de données. Voici donc une petite étude que j’ai fais concernant les Natural ID versus les Generated ID.

Premièrement, il n’y a aucune garantie que les Natural IDs ne changeront jamais, sous aucune circonstance. En fait, il y a très peu de cas où nous pouvons en être 100% sur. Les Generated ID eux ne changent jamais, sous aucune circonstance.

De plus, advenant le cas où le natural ID changerait, il faudra gérer ce changement en cascade pour chaque clé étrangère. Ce changement invalidera tous les enregistrements en cache, pour tous les niveaux de cache, autant pour la table primaire et que les tables “enfants”.

Dans un contexte de faible contrainte d’intégrité, la possibilité que quelqu’un soit tenté d’updater la …

J’ai souvent entendu parler de MySQL Sandbox. Pour effectuer des tests avec un Master/Slave en fin de semaine, j’ai décidé de l’essayer puisque je n’avais que mon laptop. MySQL Sandbox est un outil pour installer un ou plusieurs serveurs isolés, sans affecter les autres.

Wow! Juste Wow! MySQL Sandbox est un outil vraiment génial! J’ai pu créer une instance de MySQL Master avec 2 instances Slaves sur la même machine en moins de 1 minute! C’est le genre de tâche qui prend de 30 minutes à 1 heure lorsqu’un administrateur expérimenté le fait manuellement. MySQL Sandbox permet non seulement d’installer rapidement 1 ou plusieurs serveurs, il permet aussi d’installer des versions différentes en quelque instant !

De plus, des options prédéfinies permettent de créer un setup Master-Slave ou  Master-Master automatiquement. Il vient avec …

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 …

On m’a demandé un jour ce que je recommande pour des designs de databases appelées à être modifiées régulièrement. La personne prévoyait avoir besoin d’ajouter des champs fréquemment pour répondre à ses besoins.

La première interrogation qui m’est venu en tête a été de lui demander pourquoi. Pourquoi a t’il besoin d’ajouter des champs et des tables de manière fréquente ? Pourquoi ne sait-il pas d’avance ce que fera son application ? La réponse est simple: la portion de l’application qui est déjà en ligne est complètement fonctionnelle, étudiée et testée. En fait, l’application est personnalisable et chaque client qui l’achète peut avoir des particularités différentes d’un autre client. D’où le besoin d’ajouter des champs et tables régulièrement.

Il n’y a pas de réponse magique à cette question. Il suffit d’y répondre avec “le gros bon sens”. D’un côté purement …

Promouvoir un Slave en Master est une opération qu’un DBA doit faire à l’occasion, parfois pour mettre à jour une nouvelle version ou parfois pour se sortir de la m****, car le Master a rendu l’âme. C’est une opération qui n’est pas tellement difficile, mais qu’il ne faut surtout pas négliger.

1. Vérifier la configuration du Slave
Vérifiez que la configuration est semblable à celle du Master, car si vous avez promu le Slave pour vous sortir de la m****, il faut qu’il puisse soutenir la même charge que le Master avait. Gardez en tête que le Slave a originalement été configuré pour être un Slave. Il possède donc des configurations qui lui sont propres. Un bon DBA a probablement pris la peine de mettre le Slave read_only; c’est une des premières options à enlever pour promouvoir. Assurez-vous également que l’ensemble des bases de données soit répliqué, mais surtout la DB mysql pour …

Un des défis d’être francophone consiste à bien gérer l’encoding. Je ne connais aucune personne n’ayant jamais eu de problème un jour où un autre. On m’a déjà approché pour trouver la manière la plus efficace de convertir une base de données de Latin1 à UTF8. Voici ce que j’ai trouvé. Ce n’est peut-être pas la manière la plus efficace, mais je n’ai pas eu problème après l’avoir testé. J’ai utilisé cette technique pour convertir une base de données de 115Go et tout c’est bien déroulé.

L’astuce consiste à transformer les chaines de caractères à un format binaire, pour ensuite les reconvertir en UTF8.

1. ALTER DATABASE myDbNameDEFAULT CHARACTER SET utf8;
2.  
3. ALTER TABLE Groups DEFAULT CHARACTER SET utf8;
4.  
5. ALTER TABLE Groups MODIFY Domain VARBINARY(64) NULL DEFAULT NULL,
6. MODIFY Type VARBINARY(64) NULL DEFAULT NULL, …

La gestion des IP dans MySQL est très simple. Premièrement, il faut savoir que la manière la plus efficace de stocker un IP et de le représenté sous une forme numérique, soit un INT UNSIGNED (donc 4 bytes) plutot qu’un CHAR(15) de 15 bytes.

Il demeure malgré tout possible de manipuler les IP avec leur forme alphanumérique en utilisant 2 function de MySQL: INET_ATON() et INET_NTOA().

mysql> SELECT INET_ATON('192.168.20.76');
+----------------------------+
| INET_ATON('192.168.20.76') |
+----------------------------+
|                 3232240716 |
+----------------------------+

mysql> SELECT INET_NTOA(3232240716);
+-----------------------+
| INET_NTOA(3232240716) |
+-----------------------+
| 192.168.20.76         |
+-----------------------+

Si vous avez voulez savoir si un IP fait parti d’un sous reseaux, vous pouvez faire des manipulations bitwise:

SET @myIP := INET_ATON('192.168.20.76');
SET @theNetMask = …

Je dois régulièrement créer des rapports pour la comptabilité (et d’autres gens moins à l’aise avec des ordinateurs) au boulot. Le moyen facile est de leur envoyer le tout dans un fichier CSV converti en excel par email.

Il y a plusieurs manières de créer un CSV à partir de MySQL. Voici la manière que je qualifie de “standard”:

1. SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
2. FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
3. LINES TERMINATED BY '\n'
4. FROM test_table;

Une manière un peu plus rapide (trouvé en fouillant sur google):

1. mysql -umyUser-p dbName -B -e "SELECT a,b,a+b FROM test_table;" | sed 's/\t/","/g;s/^/"/;s/$/"/;s/\n//g' > filename.csv

Et maintenant.. (roulement de tambour).. “MA” manière!

1. CREATE TABLE test_table_csv SELECT a,b,a+b FROM test_table; ALTER test_table_csv ENGINE = csv; …

J’oublie parfois à quel point les tables temporaires peuvent être pratiques. On tente de sortir des rapports avec des tables qui ne sont pas prévues pour ça. On écrit des requêtes inimaginables et souvent très lentes. Résultat: on perd notre temps.

La solution: les tables temporaires ! Ce n’est pas très coûteux et drôlement pratique. Au lieu de prendre 25 minutes à écrire “une” requête qui prend un temps énorme à s’exécuter, prenez 10 minutes pour écrire 2-3 requêtes simples qui utilisent des tables temporaires et sortez le même résultat en quelques secondes!

Et si c’est efficace, performant (surtout performant) et récurrent, pourquoi ne pas transformer ces tables temporaires en view ?