Styles

jeudi 22 janvier 2009

La base de données cette inconnue...

Aujourd'hui, la plupart des applications développées sont des applications Web. Non pas qu'on ne construise plus d'autres types d'applications, mais, en quantité d'applications développées, ce sont bien les applications de types Web qui sont les plus nombreuses.

Quand on analyse ce qui constitue la plupart des applications Web, on s'aperçoit ensuite que chaque site Web est secondé par une base de données en arrière plan. Ce qui fait la force du Web c'est la facilité avec laquelle il est possible de publier des données en grand nombre et d'offrir des fonctionnalités sur ces données. Quand les années passent, les technologies de présentation des données (client lourd, client Web...) sont les premières à faire les frais de l'apparition de nouveaux concurrents. Mais, en arrière plan, la base de données est toujours là, fidèle au poste, toujours aussi importante dans l'architecture globale de l'application.

Quand on veut faire carrière dans l'informatique, on cherche à maitriser les outils dont on dispose et qui sont généralement mis en œuvre dans les projets. Personnellement, je n'ai pas le temps de réapprendre tous les 3 ans une nouvelle technologie de présentation (par exemple, en ce moment, c'est le phénomène Adobe AIR et toutes les technologies Flex qui ont le vent en poupe). Je n'ai plus l'age de passer des heures inconsidérées sur mon ordi à essayer la moindre nouveauté.


Et puis, les technologies se succédant les unes aux autres, on s'aperçoit que, bien que nouvelles, elles ne sont pas innovantes, ce ne sont que de nouvelles créations, très reluisantes, mais n'apportant pas de réelle nouveautés. Dans ce cadre là, un programmeur a tout intérêt à maîtriser au moins un système de gestion de base de données quel qu'il soit pour avoir à se pencher sur les défis réels de la mise en place de sites web : la montée en charge d'une application à accès concurrents.

Le coût global d'une requête Web sur un site Web secondé par une base de données est en grande partie due à l'accès et au traitement de la donnée, pas à se mise en forme à travers des pages HTML, Ajax, ou autre. Avec un jeu de données de test automatisé, et un grand nombre de requêtes clientes, le programmeur est tout de suite confronté à un problème de capacité. Il doit surtout faire preuve de maîtrise de son système de gestion de bases de données pour pouvoir le régler correctement pour répondre à la demande, et ce pour toutes les requêtes concurrentes.

La maîtrise d'une technologie comme Oracle, PostgreSQL ou MySQL prend déjà tant de temps que je ne vois pas où est l'intérêt de passer tout son temps sur des technologies de GUI qui évoluent au gré des modes et du temps. De toute manière, il existe de nombreux outils de développement suffisamment évolués pour ne pas avoir à taper une ligne de codes pour réaliser les tâches les plus classiques de la couche présentation.

Je ne comprend pas pourquoi tant de développeurs que j'ai côtoyé utilisent le système de gestion de base de données comme une boîte noire, comme étant juste un système de persistance d'objets. L'erreur classique est de trouver du code itératif dans une couche métier Java alors qu'une simple requête SQL aurait suffit. Les systèmes de persistance comme Hibernate ont longtemps promu des méthodes de programmation où le système de gestion de bases de données est réduit à une réceptacle abstrait et dont on doit absolument pouvoir interchanger si l'humeur nous en dit. Or, tous ces systèmes d'abstraction vis à vis du SGBD sont finalement la plus part du temps complètement inutiles sachant :

- qu'il est extrêmement rare de changer brusquement de technologies de base de données puisque, à part faire un mauvais choix, la plus part des SGBD sont maintenant extrêmement bien rodés pour ce qu'ils ont à faire.

- qu'on a tout intérêt à tirer au maximum partie des services offerts par le SGBD pour réaliser les fonctionnalités à implémenter car le paradigme de programmation SQL, bien qu'imparfait, reste toujours supérieure à une approche procédurale classique quand il s'agit de traîter des lots de données.

- si on doit utiliser un SGBD payant comme Oracle, c'est vraiment du gâchis de le considérer comme une boîte noire et de ne pas utiliser toutes les fonctionnalités que vous avez chèrement payées.

Tom Kyte résume très bien cette situation dans son livre Expert Oracle Database Architecture :
The single most common reason for database project failure is insufficient practical knowledge of the database - a basic lack of understanding of the fundamental tool that is being used. The black box approach involves a conscious decision to protect the developers from the database - they are actually encouraged to not learn anything about it ! In many cases, they are prevented from exploiting it. The reasons for this approach appear to be related to FUD (Fear, Uncertainty, and Doubt). The accepted wisdom is that database are "hard", and that SQL, transactions, and data integrity are "hard". The solution: don't make anyone do anything "hard". They treat the database as a black box and have some software tool generate all of the code. They try to insulate themselves with many layers of protection so that they do not have to touch this "hard" database.
Philip Greenspun le disait déjà de son temps dans Philip and Alex's Guide to Web Publishing :
Any interesting Web/RDBMS problem can be solved using just the standard software shipped with the RDBMS. If you can't solve it with those tools, you can't solve it with any tool no matter how glitzy and turnkey. The critical element is not the tools, it is the programmer.

In terms of maintainability, clarity of code, software development cycle, and overall Web server performance and reliability, the simplest tools such as Microsoft Active Server Pages are superior to virtually any of the expensive Web development systems out there.

Il est vraiment dommage de ne pas s'intéresser à son SGBD car il permet pourtant de réaliser de grandes applications, solides et montant correctement en charge. De plus, il permet de faire face à des situations délicates de façon élégante.

Aucun commentaire: