mysqlqa

Un code de la route version DBA. Le maillon faible puissance 10 000. Voyez ça comme vous voulez, « MySQL Question Of The Day » est un sympathique site qui vous permettra de tester vos connaissances et d’apprendre en tentant de répondre chaque jour à une nouvelle question. Bref, à suivre ! http://mysql-qotd.casperia.net

Askmonty.org

Monty Widenius, fondateur de MySQL, puis de MariaDB (suite au rachat de MySQL AB par Sun), puise son inspiration dans l’entourage familial. « Maria » est en effet le prénom de sa 2e fille, alors que sa première, elle, se prénomme « My ». Au passage, je m’aperçois qu’une recherche de « mariadb » dans Google Images retourne en second résultat ma photo de Monty en train de servir sa black vodka locale…

Source : DLFP

fk_breaker

Aux débuts de Piwam, les relations décrites dans le fichier schema.yml n’étaient pas nommées explicitement. Du coup, lors de la génération du schmilblick par Propel (Model + SQL), c’est InnoDB qui s’occupait de trouver un nom à ces relations.

Aujourd’hui, j’écris le script permettant de migrer de Piwam 1.1.2 vers Piwam 1.2, script qui nécessite d’effectuer des opérations sur des foreign keys, en l’occurence les supprimer… Comment diable alors faire référence à une clé étrangère dont on ne connait pas le nom ? Après avoir farfouillé partout sur la toile, il apparaît qu’il n’y a pas moult solutions pour arriver à mes fins. On se retrouve ainsi soit à écrire des procédures, soit à faire appel à l’information_schema. Enfin, certains proposent une utilisation de SHOW TABLE avec les arguments qui vont bien, puis parser la sortie pour récupérer les noms des contraintes. J’ai pu par ailleurs découvrir la version Firebird :

SELECT RDB$CONSTRAINT_NAME
FROM RDB$RELATION_CONSTRAINTS
WHERE RDB$CONSTRAINT_NAME LIKE 'FK%' AND
RDB$RELATION_NAME='MATABLEAMOI'
ORDER BY RDB$CONSTRAINT_NAME

Ne pouvant exécuter de requêtes propres à Firebird, ni même de procédures (Piwam tourne sous trop de types de serveurs différents aux configurations et autorisations bien différentes), j’ai finalement opté pour une solution ma foi fort simple. Accrochez-vous, c’est du SQL de très haut niveau (hum…).

CREATE TABLE ma_table_copy AS SELECT * FROM ma_table;

Une copie réalisée de la sorte a pour effet de ne copier que la structure et la table, en omettant indexes et contraintes. Lent, mais portable (je ne sais pas si l’adjectif est vraiment adapté) et pratique. Tout ça pour dire, bordel, une bonne fois pour toutes, n’oubliez pas de nommer vos contraintes explicitement, ça facilite grandement la maintenance !

Ce billet fait suite à l’article « Comment je teste #2″, qui se finissait par quelques conseils sur le profiling et l’amélioration de son code. Je vous propose de consulter une présentation réalisée par un certain George S, présentation qui fait le tour d’un large panel de possibilité pour développer du code dit « scalable » en passant donc par la configuration du serveur, l’analyse des soucis et les bonnes pratiques à adopter.

Il y a peu, une annonce était faite comme quoi MySQL travaillait sur un nouveau modèle de release. La trame générale de celui-ci est maintenant fixée et approuvée.

Dans les grandes lignes, on retrouve :

  • Le trunk est toujours laissé dans une qualité de beta
  • Les GA sortiront tous les 12 à 18 mois
  • Pas plus de 2 releases avec un support actif
  • Les milestones commencent lors de beta (jamais lors d’alpha) par un merge entre le trunk et le stage tree.

Pourquoi cet article ? Pas seulement pour relayer l’actualité MySQL, mais aussi pour tenter de sensibiliser un maximum de lecteurs sur l’importance d’un modèle de release adapté. Pour un logiciel prétendant à un minimum d’évolutions et d’activité, il est capital de trouver un compromis entre ce que je nommerai la rétro-utilisabilité et la publication des nouvelles versions. J’entends par « rétro-utilisabilité » le fait d’assurer aux utilisateurs des versions passées un support, un moyen de passer aux versions supérieures efficacement.

Source : Planet MySQL (En)

L’outil MySQL Workbench est polyglotte. Un petit nouveau vient de rejoindre la famille des plugins. Thomas Henlich publie sur son blog un plugin permettant l’export à destination des bases de données SQLite.

Un plugin qui arrive à point pour tous ceux qui sont en train de concevoir leurs applications Android ! À télécharger sur son blog.

C’est une des grandes questions de ce 21e siècle moment. Après le rachat de Sun par Oracle, que peut-on prévoir pour les différents projets relatifs à ces 2 corps qui ne forment plus qu’un ?
David Van Couvering se fait un plaisir, sur son blog, d’émettre ses hypothèses. En résumé, cela donne :

  • Glassfish : peut survivre grâce à la communauté, mais ne sera pas mis en avant par Oracle. Va mourir.
  • NetBeans : un éditeur qui devient un éditeur de trop. Va mourir.
  • JavaFX : Oracle en a rien à faire. Va mourir.
  • JavaDB : À quoi ça sert maintenant ? Va mourir.
  • MySQL : indéterminé, mais pas loin du « Va mourir ».

Bon, j’ai vraiment résumé à ma manière, l’auteur est beaucoup plus indéterminé que ça. Pour découvrir les arguments qu’il avance et comment il fait pencher sa balance, allez plutôt lire son article. Et vous, quel est votre point de vue sur tous ces produits ?

Je n’ai pas souvenir en avoir déjà parlé dans ces colonnes ; l’occasion se présente toutefois ce soir même. MySQL Workbench est un – assez – puissant outil de modélisation et conception de base de données. Libre et gratuit, il vous rendra bien des services tant en reverse-engineering qu’en conception d’un important système. Jusqu’à il y a peu, la version MacOSX était néanmoins tout bonnement inutilisable. Et depuis la dernière beta, l’équipe se montre très réactive et le retard est petit à petit comblé par rapport à l’homologue windowsien.

mysql workbench

A outil à posséder pour tous les utilisateurs de la base au dauphin. À voir et bien sûr à récupérer sur la page téléchargements de MySQL.com