L'UNION à la sauce MySQL

mardi 13 décembre 2016 :: perrick :: MySQL :: aucun commentaire :: aucun trackback

Dans la famille des "trucs" MySQL qu'on utilise pas souvent mais qui sont quand même bigrement pratique, je vous présente UNION ALL. Bien sûr la documentation en dit long :

UNION is used to combine the result from multiple SELECT statements into a single result set.

C'est quand même super pratique quand on veut - dans une même requête - afficher les temps travaillés et les absences, comme c'est le cas dans Opentime.

Mais si le commit correspondant date du 27 janvier 2015, pourquoi en parler maintenant ? Trop simplement parce qu'au détour d'un refactoring je tombe sur cet appel dont je ne me souvenais plus. Mais alors pas du tout. Un blame plus tard, je me rends compte que je n'en suis pas l'auteur : donc un grand merci à Matthieu, pour m'avoir fait découvrir ce truc. En espérant qu'il serve aussi ailleurs et plus tard...

Calculer le 95e centile avec MySQL

mardi 10 mai 2016 :: perrick :: MySQL :: aucun commentaire :: aucun trackback

Avant de mettre PHP 7 en production sur nos serveurs pour Opentime, nous avons décidé d'ajouter quelques graphes de supervision dans notre Munin. Les données sont déjà stockées dans une table SQL mais l'affichage était pour le moins sommaire. Une question est vite remontée à la surface : comment calculer le 95e centile avec MySQL ?

SELECT
 CAST(SUBSTRING_INDEX(SUBSTRING_INDEX(
  GROUP_CONCAT(field_name ORDER BY field_name SEPARATOR ','),
   ',', 95/100 * COUNT(*) + 1), ',', -1) AS DECIMAL) AS `95th Per`
 FROM table_name;

Merci à Nicolas Poggi et surtout à Roland Bouman pour les pointeurs les plus convaincants.

Migration MySQL et MariaDB

mercredi 10 décembre 2014 :: perrick :: MySQL :: aucun commentaire :: aucun trackback

Au boulot, nous avons migré plusieurs serveurs récemment : de MySQL 5.5, certains machines sont passées à MySQL 5.6 et d'autres à MariaDB. Et bizarrement ce sont les serveurs avec MariaDB qui ont posé le moins de problème.

En effet MySQL 5.6 utilise par défaut son mode strict : un certain nombre de requêtes qui passait avant ne passe plus désormais. Le paramètre que nous avons utilisé dans my.cnf, c'est sql_mode = "NO_ENGINE_SUBSTITUTION" (merci à Server Falut cette fois). Il nous a permis de laisser la production tranquille, le temps de changer la configuration de MySQL sur le serveur d'intégration continue et de corriger les requêtes dans tous les tests.

Bref, MariaDB rocks. Et les tests unitaires sur un serveur d'intégration continue bien configuré encore plus !

La limite des 50% sur une recherche FULL TEXT avec Mysql

mardi 17 septembre 2013 :: perrick :: MySQL :: 2 commentaires :: aucun trackback

Un mot qui est trouvé dans la moitié des enregistrements d'une table n'est pas efficace pour trouver les document appropriés. En fait, il trouvera sûrement beaucoup de documents inappropriés à la recherche. On sait tous que cela arrive souvent lorsqu'on recherche quelque chose sur internet en utilisant un moteur de recherche. Extrait de la documentation MySQL pour Recherche en texte intégral (Full-text) dans MySQL

Sauf que dans le cas du petit corpus de questions / réponses que compose la section FAQ d'Opentime et encore plus dans le minuscule corpus généré pour mes tests unitaires, ce seuil de 50% m'a fait arracher les cheveux pendant 2h. Et la solution pour outre-passer cette limitation est sur la page suivante de la documentation : il suffit d'ajouter l'option IN BOOLEAN MODE. Elle permet - entre autres - de ne pas utilise pas le seuil de 50%. Problème : elle ne trie pas automatiquement les lignes par ordre de pertinence décroissante. Heureusement qu'il y a encore d'autres astuces possibles : MySQL match() against() - order by relevance and column.

Trier par pertinence avec MySQL

lundi 14 novembre 2011 :: perrick :: MySQL :: 5 commentaires :: aucun trackback

Ce n'est pas tous les jours que je découvre des petits trucs avec MySQL et la synaxe SQL en général. Alors voici ma dernière production :

SELECT `contact`.* FROM contact WHERE (contact.lastname LIKE '%gra%' OR SOUNDEX(contact.lastname) LIKE SOUNDEX('gra') OR contact.firstname LIKE '%gra%' OR SOUNDEX(contact.firstname) LIKE SOUNDEX('gra') OR contact.company LIKE '%gra%' OR SOUNDEX(contact.company) LIKE SOUNDEX('gra')) LIMIT 0,10

Cette requête permet de sélectionner des contacts en fonction de leur nom, de leur prénom ou de leur entreprise, mais aussi avec une orthographe approchante via la fonction SOUNDEX. Elle marche, elle est en production depuis plusieurs années. Seul problème : le tri, surtout quand on trouve plus de 10 réponses. Comment distinguer facilement les réponses en orthographe précise de celles qui s'en approchent seulement ?

SkySql se lance dans le grand bain

mercredi 13 octobre 2010 :: perrick :: MySQL :: aucun commentaire :: aucun trackback

Il y a des petites histoires qui font leur chemin... La présence et les discours de Monty (ex-Mysql) lors du Forum PHP 2009 finiraient bien par déboucher sur quelque chose : il y avait eu tellement de petites phrases à l'époque. Désoermais c'est chose faite, SkySQL a ouvert ses portes aujourd'hui... On retrouve aussi dans l'équipe de cette nouvelle société Michael Carney que les visiteurs au Forum connaissent bien : il nous avait présenté plusieurs conférences au fil dans ans.

C'est toujours rigolo de tirer les implications de la présence des uns et des autres lors d'un évènement comme le Forum PHP. Reste à voire quelle sera la surprise pour 2010 !

Et de mon côté il me reste probablement à renommer cette rubrique dans le blog : Databases, Base de données, *SQL ? D'autres idées ??

Le grand saut de l'utf8

vendredi 23 mars 2007 :: perrick :: MySQL :: 3 commentaires :: aucun trackback

Aujourd'hui on fait des ALTER, c'est en tout cas ce que je pensais : UTF8 et MySQL n'étaient -- dans mon esprit -- pas encore en bon terme. Et finalement il aurra suffit d'une boucle pour migrer toutes les tables d'openTIME.

Rigolo comment des passages deviennent naturels parfois : Tout en utf-8 de Laurent, Convertir un site en UTF-8 de Nicolas, détour via PHP/Oracle de Gérald. Et donc notre logiciel de gestion de temps qui a suivi hier le même chemin, pour une sombre histoire de Selenium Server.

C'est dans ces moments-là que je me dis que PHP6 a un bel avenir devant lui : plus de soucis avec urlencode, plus de soucis avec strtoupper. Le bonheur en barre à portée de clavier.

Sage, du côté de MySQL

mercredi 1 novembre 2006 :: perrick :: MySQL :: aucun commentaire :: aucun trackback

Ce n'est pas souvent que je parle de MySQL : c'est une des catégories un peu délaissées de ce blog. Par contre j'ai appris aujourd'hui que Sage va embarquer la base de données open source MySQL. Pour l'instant Sage peut utiliser la technologie MySQL pour l'ensemble de ses produits à travers le monde : reste à savoir quand et si cette migration aura lieu. Vu qu'on travaille régulièrmeent pour des clients qui utilisent ces outils de comptabilité et de gestion, ça pourrait révolutionner notre boulot : une affaire à suivre donc.

Attention à TRUNCATE avec une table Inno DB

vendredi 7 octobre 2005 :: perrick :: MySQL :: 10 commentaires :: aucun trackback

Le truc avec les tests c'est qu'ils sont automatiques et précis. Très précis même. Donc quand ils renvoient un ID avec comme valeur "2" et que moi je m'attendait à une valeur "1", c'est qu'il y a un problème quelque part : une chose est sûr l'insertion de ma valeur dans la table de test ne marche pas comme il faut. Quand bien même tout à l'air de fonctionner dans l'application (un plugin pour openTIME). Après plusieurs tentatives infructueuses pour trouver l'origine du problème, je m'étais résolu -- bien malgré moi -- à accepter cette "fausse valeur".

Aujourd'hui ça recommence pour une nouvelle table : à une différence prêt, nous sommes vendredi soir et la pression de la semaine est tombée quelque peu. En creusant un peu, le problème vient d'un TRUNCATE table qui ne fonctionne pas à tous les coups. Au passage je me rends compte que mes nouvelles tables n'ont pas de type : MySQL par défaut se charge de les créer en Inno DB, alors que dans le reste d'openTIME j'utilise des tables MyISAM. J'ai eu du mal à commencer une recherche dans le manuel de MySQL : je n'ai encore jamais eu à faire à un bug dans des versions "stable". C'est donc choses faite : MySQL Bugs: #11946: truncate does not clear the auto_increment in innodb tables. Et il ne me reste qu'à attendre (et installer) MySQL 5 pour que le bug soit corrigé définitivement.

La doc pas si bien faite de MySQL

mardi 16 novembre 2004 :: perrick :: MySQL :: 3 commentaires :: aucun trackback

Une des règles les plus courantes du développement tient en qq lettres : RTFM (lire le put**n de manuel). Et pourtant je viens de m'arracher les cheveux sur celui de MySQL à cause d'une information manquante et pourtant simple : les fonctions CONVERT et CAST ne sont apparues qu'à partir de la version 4. Si vous avez encore des serveurs qui tournent avec une version 3.23, passer votre chemin.

Un grand merci quand même à la fac d'Amsterdam (il y en a probablement d'autres) qui héberge encore le manuel de référence de MySQL pour sa version 3.23. C'est là que j'ai lu : «we plan to soon introduce casting between different character sets to make string comparison even more flexible».

Pour en revenir à mon problème (ne pas différencier dans ma requête les champs 0 et NULL tout en présent l'information dans la table), j'ai du faire appel à une astuce pas forcément très catholique mais qui a au moins le mérite de marcher : SELECT GREATEST(start, 0) as start FROM table.

PS : c'est dans ces cas-là qu'on se rend compte que la doc de PHP est vraiment très bien foutue.

Trouver le lundi de la semaine en cours

mercredi 22 septembre 2004 :: perrick :: MySQL :: 2 commentaires :: aucun trackback

Cela fait pas mal de temps que je n'ai rien mis dans cette catégorie MySQL alors qu'elle figure en bonne place dans le titre de ce blog : faudra peut-être que j'y fasse quelque chose...

En attendant voici un petit truc pour trouver la date du lundi de la semaine en cours :
SELECT DATE_ADD(CURRENT_DATE, INTERVAL(- DAYOFWEEK(CURRENT_DATE) + 1) DAY).

Et pour la même chose au format timestamp :
SELECT UNIX_TIMESTAMP(DATE_ADD(CURRENT_DATE, INTERVAL(- DAYOFWEEK(CURRENT_DATE) + 1) DAY)).

Comment j'en suis arrivé là ? Tout simplement pour que le script d'installation d'openTIME soit le plus indépendant possible de PHP.

Mise-à-jour du 23/09/2004 : trouver un exemple plus probant de test unitaire en lien avec une base de données ne pouvais pas être plus évident, j'ai donc corrigé la fonction ci-dessus.

Pour un gourou MySQL...

samedi 28 février 2004 :: perrick :: MySQL :: 4 commentaires :: aucun trackback

En avançant dans ma couverture de tests pour openTIME -- toujours grâce à eXtreme Programming, je découvre quelques subtilités de PHP et de MySQL.

Pour mon premier l'analyseur de code PHP qui devrait m'aider à localiser les functions qui ne sont plus utilisés. J'en reparlerai un jour si ça dépasse le stade du carton. A moins qu'un bon outil de refactoring pour PHP sorte ou que quelqu'un me donne une URL intéressante pour découvrir qu'il existe déjà.

Et pour mon second, dans la famille "bug ou feature", un test à réaliser soit même : faire la recherche SELECT * FROM ma_table WHERE id = '1a'; sur une table MySQL 'ma_table' qui contient une colonne id de type int et un seul enregistrement où id = 1. Je suis curieux de savoir pourquoi avec MySQL 4.0.15 et MySQL 3.23.58 je trouve mon enregistrement. Au lieu de rien ?

MySQL et PHP : une explication en cours

mercredi 16 juillet 2003 :: perrick :: MySQL :: 2 commentaires :: aucun trackback

La version 5 de PHP ne contiendra pas de client pour la base de données MySQL : la nouvelle avait surpris pas mal de monde. La raison ? Une incompatibilité de licence entre la GPL (MySQL depuis la version 4) et la BSD (PHP).
Pour y voir plus clair : un entretien entre Zak Greant -- MySQL AB Community Advocate -- et le magazine php | architect.
Via http://dev.nexen.net/news/.

MySQL et SAP : vers le haut ?

lundi 2 juin 2003 :: perrick :: MySQL :: aucun commentaire :: aucun trackback

Bien sûr je me réjouis de voir la fusion entre MySQL et SAP-DB (ou ici - en anglais) : un champ complet de fonctionnalités devrait s'ouvrir pour les développeurs autour de ce nouvelle base de données... Bref ça concorde avec l'impression que MySQL souhaite se faire une place dans le haute-sphère des bases de données "d'entreprises".

Mais parallèlement, SAP fait sa pub dans les gares (à Lille Flandres et Paris Nord au moins) pour les PME/PMI - et non pour les grands comptes : est-ce que ça veut dire que la firme allemande souhaite bénéficier d'une base de données plus simple (et moins chère) pour ses "petits clients" ?

Du MySQL partout

jeudi 27 mars 2003 :: perrick :: MySQL :: aucun commentaire :: aucun trackback

Il n'y pas si longtemps que ça, MySQL n'avait les faveurs des utilisateurs "sérieux". Et depuis quelques temps, ça change.

J'avais d'abord noté que FogBUGZ - le logiciel du Joel de Joel on Software fonctionne aussi sur MySQL. Là Joel appelle ça "transformer ses compléments en biens courants".

Ensuite la version 4.0 de MySQL passe enfin en production avec son lot impressionant de fonctionnalités.

Enfin aujourd'hui, j'apprends que Sage peut faire ses logiciels de comptabilité sous MySQL (là je n'ai pas de liens donc on dira que c'est une "rumeur", en attendant une source directe).

Au fait, mon outil - openTIME - tourne aussi sous MySQL. De là à dire que je suis biaisé, c'est à vous de le penser, ou non ;-)

1 2 >>