Bienvenue sur Think-Underground.com

J'ai découvert récemment Francocube, un site qui propose des méthodes pour résoudre la majorité des variantes de Rubik's cube.

On a (presque) tous un de ces cubes à la maison, chez nos parents ou chez un ami plus ou moins proche (et plus ou moins fou)… toujours est-il qu'en général, les gens qui l'ont eu entre les mains pour la première fois l'ont souvent reposé au bord de la crise de nerfs. Heureusement, il n'est pas si difficile de résoudre ces casse-tête à condition d'avoir quelques explications de méthodologie, c'est-à-dire surtout de savoir dans quel ordre s'y prendre !

Francocube fait le tour des diverses méthodes et donne aussi des « formules » qui guident pas à pas la résolution. Si l'application bête et méchante de formules n'est pas forcément la finalité de ce casse-tête, c'est au moins un bon point de départ pour pouvoir reconstruire le cube sans devoir décoller les faces

Personnellement je me suis bien amusé il y a quelques années avec un Rubik's cube classique (3×3), et c'est l'achat relativement récent d'un Megaminx — c'est à dire d'un Rubik's cube dodécaédrique — qui m'a poussé à chercher une méthode plus constructive que mon approche à tâtons. Et tout à coup ça marche mieux !

Allez, à vos cubes !

Si vous connaissez déjà relativement bien le langage SQL, vous savez probablement que EXPLAIN sert à détailler les étapes de l'exécution d'une requête par le serveur (execution plan).

Le site Explain Extended pousse le concept un peu plus loin. Il prend des problématiques classiques en SQL, les résout, puis optimise la trace d'exécution pour rendre la requête le plus rapide possible. Il utilise toutes les possibilités et contourne les limitations de plusieurs SGBD : MySQL, SQL Server, Oracle, PostgreSQL…

Personnellement j'y ai appris pas mal de choses. Par exemple alors que je cherchais à calculer le score moyen de joueurs sur leurs 10 dernières parties (ou moins s'ils n'avaient pas encore fait 10 parties), j'y ai appris l'utilité (et par là même l'existence) de la fonction COALESCE.
Plus récemment sa réflexion sur l'utilisation de UNPIVOT m'a permis de comprendre qu'il ne fallait pas toujours rechigner à utiliser certaines fonctions peu populaire et ayant une mauvaise image lorsqu'elles sont adaptées à un besoin.

Une lecture que je recommande à tout amateur ou prétendu expert en bases de données.

̂

Sinon, pour les curieux, ou ceux qui veulent optimiser mon bouzin (qui tourne déjà en mois d'une milliseconde sur ma petite base) :

SELECT 
   `joueurs_id`, 
   `joueurs_nom`, 
   `joueurs_prenom`, 
   `moyenne_instantanee`, 
   `nb_parties` 
 FROM joueurs 
 INNER JOIN ( 
   /* Calcul de la moyenne instantanée du joueur */ 
   SELECT 
     stats.`stats_joueurs_id`, 
     SUM(`stats_score_apres` - `stats_score_avant`)/COUNT(`stats_date_partie`)
          AS moyenne_instantanee, 
     COUNT(`stats_date_partie`) AS nb_parties 
   FROM stats 
   INNER JOIN ( 
     /* Calcul de la date de la plus vieille des 10 dernières parties (ou moins) */ 
     SELECT 
       `stats_joueurs_id`, 
       COALESCE(( 
         SELECT `stats_id` 
         FROM `stats` 
         WHERE `stats_joueurs_id` = v_parties.`stats_joueurs_id` 
         ORDER BY `stats_id` DESC 
         LIMIT 9,1 
       ), 0) AS stats_id_vieille_partie 
     FROM ( 
       /* Sélection des parties d'un joueur */ 
       SELECT 
         `stats_joueurs_id`, 
         `stats_date_partie` 
       FROM stats 
       GROUP BY 
         `stats_joueurs_id`, 
         `stats_date_partie` 
     ) AS v_parties 
     GROUP BY `stats_joueurs_id` 
   ) AS v_dates 
   ON stats.`stats_joueurs_id` = v_dates.`stats_joueurs_id` 
   AND stats.`stats_id` >= v_dates.`stats_id_vieille_partie` 
   GROUP BY stats.`stats_joueurs_id` 
   ORDER BY stats.`stats_joueurs_id` 
 ) AS v_moyennes 
 ON v_moyennes.`stats_joueurs_id` = joueurs.`joueurs_id`