Faisant suite à l’article sur la création d’;une table MySQL de pays, voici un deuxième script d’importation qui lui vous permettra d’ajouter dans votre base de données tous les départements français.

Trois colonnes, simplement et efficacement :

1. Id du département,
2. Code du département : numéro officiel régional,
3. Nom du département.

Comme d’habitude, la table est encodée en UTF-8, avec le moteur InnoDB, pour pouvoir gérer les clefs étrangères, utilisées presqu’obligatoirement avec ce genre de tables.

Table MySQL des départements français

[Edit du 28 octobre : mise en ligne de la bonne version]

Nous allons aujourd’hui traiter d’optimisation MySQL, en nous penchant sur le cas des alias de table. Ceux-ci ont-ils un réel impact sur les performances de nos requêtes ? C’est ce que nous allons voir dans ce billet.

Lorsque vous écrivez une requête SQL, il est possible de spécifier un alias au nom des tables que vous utilisez. Cela permet d’utiliser plusieurs champs portant le même nom dans des tables différentes tout en réduisant le nombre de caractères de votre requête. Un exemple sera bien plus parlant qu’un long discours :

Cependant, on peut se demander si ces alias ont un impact au niveau des performances de ces requêtes. On pourrait supposer que les alias de tables sont favorables aux performances. Mais qu’en est-il réellement ?

On spécifie explicitement au serveur le nom des tables dans lesquelles il doit rechercher le champ spécifié. Ainsi, il n’a pas à le déterminer lui-même, en parcourant la structure de toutes les tables présentes dans la requête. Ce qui pourrait nous laisser croire que l’utilisation des alias optimise nos requêtes. Vérifions donc notre théorie.

Pour ce faire, effectuons quelques tests d’exécution de requête sur une et deux tables, en faisant varier la présence d’alias et le moteur de bases de données. On obtient les résultats suivants (chiffre moyen basé sur l’exécution de 10.000 requêtes sur le même serveur de développement) :

InnoDB :

Une table, sans alias : 4.358 ms
Une table, avec alias : 4.382 ms
Deux tables, sans alias : 5.485 ms
Deux tables, avec alias : 5.421 ms

MyISAM :

Une table, sans alias : 4.488 ms
Une table, avec alias : 4.449 ms
Deux tables, sans alias : 5.376 ms
Deux tables, avec alias : 5.406 ms

Ainsi, comme nous pouvons le constater, les alias de tables n’ont aucun impact sur les performances. Cependant, ils permettent d’accroître grandement la lisibilité de vos requêtes, ce qui au final, accroît tout de même votre productivité en tant que développeur. La mort des alias n’est donc pas encore pour aujourd’hui. ;)

Lors de l’implémentation d’un script d’import massif d’adresses emails (environ 120.000 adresses), je me suis buté à une lenteur non négligeable de mon script. Plus de deux heures pour effectuer l’import. Je ne pouvais pas me permettre de laisser une telle longueur d’exécution pour mon ego personnel mes clients. :p

Après avoir essayé d’optimiser un maximum le code, je n’ai pas réussi à optimiser énormément le script. Je me suis donc penché du côté de la base de données. Je me suis donc amusé à modifier le moteur de ma table. Plusieurs choix m’étaient possibles, mais seuls deux me parlaient réellement, suite à la lecture de différents articles et à mon expérience personnelle : InnoDB et MyISAM.

InnoDB est un moteur de recherche prenant en charge les contraintes de clefs étrangères (ce qui me fait l’utilier le plus souvent), les transactions avec commit et rollback. MyISAM lui n’intègre pas toutes ses vérifications. Il est donc, en théorie, plus rapide. Il est d’ailleurs plebiscité pour les grosses requêtes de type SELECT. Cela ne nous intéresse pas dans notre cas (uniquement des INSERT). Qu’en est-il donc de ce changement de moteur ?

Pour faire mes tests, je me suis basé sur l’insertion de 500 enregistrements. Voici les temps moyens d’exécutions :

InnoDB :	41.4224 s
MyISAM :	0.1716 s

On constate donc que MyISAM est bien plus rapide qu’InnoDB. Moralité : employer MyISAM si aucune fonctionnalité avancée de MySQL ne doit être utilisée. Dans mon cas, cela a allégé la durée d’exécution de script : de deux heures, je suis passé à une minute. D’où un gain merveilleux. Et des clients satisfaits. ;)

Voici un script SQL fort utile permettant la création d’une table countries regroupant tous les pays existant dans le monde. Elle en recense 246, conformément à la norme ISO 3166-1.Cette table contient trois champs.

1. id : Clef primaire de la table
2. name : Nom français du pays
3. code : Code Alpha-2 du pays

A noter que la table est encodée en UTF-8, en utilisant le moteur de stockage InnoDB, très utile pour toute la gestion des clefs étrangères que vous ne manquerez pas de faire. ;)

Télécharger la table SQL des pays du monde

[EDIT : Correction de "\n" en trop dans les codes Alpha-2.]

Pour tous les étourdis du Web (dont je fais partie), il peut arriver d’oublier son mot de passe WordPress. Pour le réinitialiser, rien de bien difficile. Il suffit uniquement de posséder un accès à la base de données de votre blog, et de changer le mot de passe, en n’oubliant pas de le crypter en MD5.

C’est tout pour aujourd’hui.