Update sur de tres grosses tables

CREATE TABLE `sbtest2` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
`c2` char(120) NOT NULL DEFAULT '',
`pad2` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=20000001 DEFAULT CHARSET=latin1;

alter table sbtest2 disable keys;
insert into sbtest2 select id,k,c,upper(pad),c2,pad2 from sbtest;
/* rebuild index*/
alter table sbtest2 enable keys;
alter table sbtest2 engine='InnoDB';

mysql backup script

Une fois installée votre première base de donnée Mysql sur un os Windows qui n’est pas un poste de développeur, vous deviendrez par définition un DBA et la tâche la plus importante de celui-ci est … la sauvegarde des données.

Vous irez souvent chercher sur le net un script tout fait qui face cela simplement et la plupart d’entre eux utilise une méthode simple mais qui a fait ses preuve, l’utilitaire mysqldump.

Voici un script un peu plus complet que la moyenne, gèrant un bug pernicieux du ERRORLEVEL sous Windows, et sauvant en plus les routines et la table d’évènements. Et testé depuis un an en production.

Il gère les sauvegardes à chaud, à froid (service coupé, la méthode la plus fiable), incrémental (fichiers binlogs), et vous envoyant un mail de rapport si spécifié.
J’aimerais le compléter avec une gestion des binlogs plus poussé, la compression des fichiers, des méthodes de sauvegardes plus complètes voir le support des snapshots

Le zip fourni contient le script, un fichier de configuration et un utilitaire d’envoi de mail.

mysqlbackupscriptTéléchargement

Je vous recommande également la lecture de cet article de la documentation officielle:
http://dev.mysql.com/doc/refman/5.0/fr/backup-policy.html

Pour une solution plus complète, regardez les solutions commerciales zmanda recovery manager ou mysql enterprise backup

De l’arrivée des ORMs

En passant

projet pour la fontaine de l’éléphant de la Bastille, Aquarelle de Jean-Antoine Alavoine (1776-1834)

Un des changements récents et inévitable de notre nouvelle ère numérique est l’objectivation  des bases de données, et l’introduction des ORMs. Je me frotte a ces beautés fatales depuis plusieurs années et si les débuts furent assez séduisants mais houleux, j’en conclus avec le recul que l’évolution est incontournable.
Essentiellement de part la proéminence des langages objects : même si C tient le haut du pavé sur Tiobe, C++ C# et java sont juste derrière (voir devant depuis janvier). Quoi de plus naturel que de persister directement les objets en bases, sans mapping manuel qui est source d’erreurs.

Seulement, ces outils puissants sont aussi complexes et ne remplacent pas une connaissance minimale de SQL, faute de se tirer une balle dans le pied. Si vous ne regardez pas les requetes générées ou le modèle, attention aux surprises lors de la mise en production. Sur de gros volume de données, cela pardonne moins facilement.

Vous serez donc bien aise de lire les mauvaises pratiques d’hibernate et d’autres avant de vous lancer plus en avant, et de trouver un bon tutoriel (ici pour nhibernate).

A contrario, il existe de nombreux cas où l’utilisation d’un ORM est trop coûteux, et vos premiers projets avec cette technologie seront bien sur plus lents.

Je vois plusieurs effets directs de cette arrivée à maturité des ORM :

  • un premier est que les développeurs s’intéressent plus à ce qui se passe coté base de donnée et vont moins faire de copier/coller, sans doute parce que l’ORM les soulage des tâches les moins nobles
  • un autre est que les couches d’accès aux données peuvent se simplifier considérablement,
    il est possible de les faire tenir en une centaine de ligne nonobstant les entités.
  • un dernier est le blowback, l’arrivée des noSQL, non pas pour stocker des grosses quantités de données, mais pour s’astreindre des difficultés de la modélisation (et je rejoins l’avis de monty).

Un cas classique est le stockage d’objets sérialisés (en json, ou en xml) sur des bases jeunes (mongoDB) ou des graphes d’objets dans des blobs… avec les médiocres performances ou la perte de fonctionnalités: plus de critères, plus de compatilité ascendante.

Les développeurs ne savent-ils plus modéliser, ou le DBA n’a-t-il plus de rôle  ? C’est un éventualitée mais dans ce cas c’est effectivement la fin de vie des SGBDR car ils ne sont performants qu’avec des modèles bien fait.

La prochaine étape sera peut-être alors le retour en grâce des bases de données objets qui existent depuis nombreuses années mais n’ont pas réussit à s’imposer face aux SGBDR traditionnels, même s’ils sont plus performants sur les opérations de CRUD.
A moins que les SGBDR n’intègrent de plus en plus l’objet… A cet égard, l’exemple CRUD de mysqlcluster est impressionant.

Ou alors des SGBDR qui crée

Une anecdote pour finir: savez-vous que Posgresql gère l’héritage de table depuis la version 7 ?