Préambule technique à une série de futurs articles, je ne vous en dis pas plus, l’épisode du jour a pour point de départ un moteur de stockage MySQL avec à la clé la possibilité, ou pas, de définir l’implémentation de ses index : B-TREE ou HASH.

Ce choix n’est en effet pas toujours disponible, c’est même plutôt rare puisque seul le moteur de stockage MEMORY vous permet depuis la version 4.1 de MySQL, d’effectuer ce choix. Nous ne parlerons pas ici du MySQL Cluster et de son moteur NDB qui sera abordé spécifiquement dans un autre épisode.

Pourquoi alors se soucier de ce type d’implémentation si seul le moteur MEMORY offre la possibilité de choisir ?
- MyISAM et InnoDB pourraient à l’avenir proposer ce choix.
- Afin de comprendre plus finement comment fonctionnent les index que vous utilisez tous les jours, se pencher sur la façon dont ils sont implémentés permet de mieux appréhender …

Modifier une petite ligne dans le fichier de configuration de son SGBD et obtenir les performances souhaitées, c’est possible… si vous êtes chanceux. La performance globale d’un SGBD repose en effet sur un ensemble de briques, logicielles ou matérielles, qui une fois empilées correctement forment un ensemble cohérent (et performant) : la seule étape du fichier de configuration ne suffit pas.

Dans un de ses récents billets, Matt Yonkovit a déclenché une série de réflexions intéressantes à propos de l’impact des performances des disques durs sur l’ensemble du SGBD.

Selon lui, les problèmes de performance au sein d’un SGBD sont la plupart du temps relatifs aux disques durs et notamment au nombre d’I/O (Entrées/Sorties) qu’ils …

Bonjour à tous, premier post sur dbnewz, c’est donc l’occasion de me présenter.
En quelques mots, je suis d’abord un passionné d’internet. J’ai la chance de travailler dans le domaine qui me passionne depuis 2000. D’abord ingénieur développement puis rédacteur/auteur et à nouveau ingénieur développement, c’est dans la peau d’un “ingénieur bases de données” que j’ai assisté à la dernière MySQL Conference. Pour la petite histoire, c’est lors d’un “MySQL Quizz Show” pas avare en soda et pop-corn, que le père de dbnewz aka “pébé” m’a proposé de participer à ce blog. Vous savez tout, ou presque : la rubrique “à propos” a également été mis à jour.

Les présentations étant faites, retour au sujet de ce premier billet : la récente MySQL Conference. Si vous n’avez pas eu la chance d’y assister (elle se tenait du 14 au 18 avril dernier à Santa Clara), surtout …

En regardant le blog de Colin, je ne peux m’empecher de penser à ces très bons moments passés à Heidelberg…
Voilà la photo:

ET C’EST PARTI pour l’édition 2008 de la MySQL UC. Quel plaisir de retrouver les membres de la communauté! Le premier jour est consacré aux tutoriaux. J’ai choisi de suivre:

• Building Scalable & High Performance Datamarts with MySQL
• SQL Antipatterns

Nous allons parler de Datamarts toute la matinée, pour l’instant nous en sommes à la partie technique… j’attends la partie consacrée à MySQL.

Voici mon problème du jour : Comment lancer un script (de maintenance par exemple) qui fait appel à mysql, sans stocker en dur le nom de l’utilisateur et le mot de passe (ce qui est mal, très très mal). Le but est que seul un utilisateur privilégié (je n’ai pas forcément dit root ! je pense plutôt à un compte système comme mysql par exemple) puisse lancer ce script.

C’est plutôt facile, et je fournis trois solutions pour la peine :

1. Avoir un fichier de configuration pour le script accessible seulement par l’utilisateur privilégié

   On définit dans le fichier de configuration des variables d’environnement, une pour le user, une autre pour le mot de passe. Dans le script il ne reste qu’à utiliser la commande source pour récuperer ses variables (seul l’utilisateur privilégié pourra lire le fichier). Simple et efficace.

2. Avoir un fichier de …

MySQL AB est une compagnie mondiale. La plupart des employés sont de part le monde et travaillent de chez eux. Les échanges se font le plus souvent par emails, blog, téléphone, IM et IRC. Une fois par an, ils se retrouvent pour un “MySQL Developer Meeting”. Cette année encore, cette rencontre a lieu à Heidelberg en Allemagne et débute aujourd’hui 19 Septembre 2007 pour finir dimanche. Suite au billet de Kaj qui a rendu la nouvelle officielle, nous y avons appris que certaines personnes de la communauté sont invités à y participer. J’y serai à partir de ce soir et essayerai de vous tenir au courant des nouveautés qui ne sont pas confidentielles. En effet j’ai du signer un accord de confidentialité.

Je viens de lire récemment Sécurité PHP 5 et MySQL, écrit par Damien Seguy et Philippe Gamache. J’ai évidement commencé par les parties que me tiennent à coeur, MySQL et en particulier:

• Risques liés aux bases de données
• Vulnérabilités des base de données
• Mesures de sécurité pour MySQL

Je vous le conseille, vous trouverez un condensé de tout ce qu’il faut savoir à ce sujet pour protéger vos bases de données. Merci messieurs!
Je vais m’attaquer à la partie PHP

J’ai eu un petit problème sympa à résoudre. En résumé, nous avons 2 tables t1 et t2.

mysql> select * from t1;
+——+——+
| id | name |
+——+——+
| 1 | a |
| 2 | b |
| 3 | ab |
| 4 | bc |
+——+——+

mysql> select * from t2;
+————–+———+
| dependent_id | base_id |
+————–+———+
| 1 | 1 |
| 3 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 3 | 2 |
| 4 | 2 |
+————–+———+

Nous ouvrons une transaction (T1) et nous exécutons la requête suivante.

SELECT * FROM t1 JOIN t2 WHERE t1.id=t2.dependent_id AND t2.base_id=1 FOR UPDATE;

+——+——+————–+———+
| id | name | dependent_id | base_id |
+——+——+————–+———+
| 1 | a | 1 | 1 |
| 3 | ab | 3 | 1 …

Kaj réagit aux discussions d’hier. Mais qu’est ce que cela va changer pour le user landa? Va-t-il se tourner vers la version enterprise? Sachant que j’ai encore des serveurs qui tournent MySQL du 3.23, du 4.0 et du 4.1, cette restructuration aura-t-elle un impact pour moi? Non je ne crois. Pour des grosses sociétés, tous les bugs sont trouvés en phase de test… si la version courante est buggé, je prendrais la précédente.