Steve reçut un appel frénétique d'un client, le suppliant de l'aider à optimiser leur plus gros système de gestion des commandes clients. En production depuis moins d'un an, le système tournait aussi rapidement qu'une tortue en fin de vie, même après avoir surdimensionné le hardware. Rien de tout ça n'avait surpris Steve; après tout, c'était un jProjet.
Les jProjects, connus dans toute la société, sont des projets voués à l'échec ou à devenir le pire cauchemard de ceux qui héritent de la maintenance. Les jProjects sont, sans exceptions, dirigés par le développeur vedette de la société, Jay. En plus d'être innovant, Jay réussit à mettre en exergue les vices architecturaux de la programmation, des bases de données ou de tout autre outil tiers lors du développement de sa propre architecture.
Sur le système de gestion des commandes, le ralentissement provenait d'un bug de SQL Serveur qui n'indexait pas correctement les pages de table. Le design de Jay était brillant : chaque commande avait sa propre table. De cette façon, qu'importe le changement de la structure du modèle de commande, cela n'affectait pas celles passées. Quel génie ce Jay !
Après avoir passé quelques jours à combiner l'hérétique nombre de tables de commandes, Steve fut en mesure d'augmenter considérablement les performances et réduisit la taille de la base de 80GB à 2Gb. Jay, toujours développeur vedette, se moqua de la bidouille et dit qu'il préférait se tourner vers des SGBDR plus robustes pour ses prochains (j)projets.
