On peut lire ça et là, depuis un certain temps, que la base de données n’aurait aucune espèce d’importance. Il suffirait d’utiliser un mapping objet/relationnel et de se reposer sur un mythique cache, sorte de panacée à tous les maux.

Pour le compte de ses clients, nos équipes ont effectué plusieurs dizaines d’audits de performances sur diverses applications en grande difficulté de performance. Et les faits sont sans appel !

Dans une majorité des cas, les causes des mauvaises performances se situent au niveau de la base de données !

Pour compléter le tableau, il faudrait ajouter à cela les problématiques d’entrées / sorties en général :

  • accès aux fichiers,
  • invocations de composants distants via le réseau (EJB, services Web, .NET remoting …),
  • envois de requêtes SQL (encore la base de données !).

Malheureusement, l’aspect base de données est trop souvent négligé. Ainsi, il n’est pas rare de trouver en production des bases de données qui n’ont d’autres index que les clés primaires, et dont les performances s’écroulent lamentablement à mesure que la volumétrie croît. Ne sont pas rares non plus, ces applications qui assaillent litéralement la base de donnée sous un flot incessant de requêtes SQL (des rafales de requêtes), pour finalement faire très peu de choses. On pourrait aussi évoquer certaines requêtes SQL qui écrasent à elles-seules la base de données, personne n’ayant pris le temps de vérifier leur plan d’exécution. Que dire aussi du refus idéologique des procédure stockées qui sont pourtant, dans certains cas, le seul moyen d’avoir de bonnes performances ?

Une évidence s’impose : il faut prendre en compte et gérer ces problématiques.

Et les développeurs de dire en choeur : « c’est le DBA qui doit s’en occuper ! »
Et le DBA de répondre en solo : « je veux bien les aider, mais il ne viennent me voir que quand tout va mal ! »

Finalement, ces problèmes fondamentaux, personne ne s’en occupe vraiment !
Le no-man’s-land de la base de données sépare deux territoires : developpeur-land et dba-land !

En fait le problème relève de la responsabilité de tous, à la fois des développeurs, du DBA …. et surtout de l’architecte-projet !

  • L’architecte projet élabore le schéma de la base avec le DBA …
  • Il évalue les volumétries … avec le DBA …
  • Il envisage la mise en oeuvre du clustering ou du partitionnement, si les volumétries sont atypiques … et avec le DBA …
  • Il veille à éviter les rafales de requêtes en sensibilisant les développeurs …
  • Il éveille les développeurs à l’écriture et à l’optimisation des requêtes SQL …
  • Il suggère des index et décide collégialement … avec le DBA …
  • Il veille à garder une vision claire du schéma et des ses inévitables évolutions au cours du développement …
  • Il prépare la mise en production de l’application … avec le DBA …

Bref, il contribue à faire disparaître le no-man’s-land de la base de données, dans l’intérêt du projet !