Ma valise de programmeur
Accueil du site > Essais > Databases overkill !

Databases overkill !

lundi 1er décembre 2008, par Etienne Charignon

Beaucoup d’applications développées de nos jours souffrent d’avoir été basées à priori sur une architecture avec une base de données. Cette décision systématique est la cause de grand maux.

Cela faisait un moment que cette réflexion me démangeait, mais je n’arrivais pas à en sortir quelque chose. C’est parfois comme ça quand l’émotion occupe trop le champ. Comme cela m’énerve que les bases de données aient une telle "légitimité".

Et voila que je viens de lire le dernier poste de Martin Fowler. Quel plaisir et quel soulagement de voir, si bien exposé, ce sujet qui me travaille tant !

DatabaseThaw

En résumé, les bases de données relationnelles sont utilisées parce qu’elles permettent de mettre en place le motif d’"intégration par le partage de la bases de données". Ce qui sous-entend que l’hégémonie des bases de données relationnelles est due au langage SQL.

Comme le fait remarquer Martin Fowler, cela pose un grave problème d’encapsulation des données.

Pour Martin Fowler l’espoir est dans l’"intégration par le web", avec comme langage : HTML.

Bien que le message de Martin Fowler traite en particulier des bases de données relationnelles, je m’intéresse plus particulièrement à l’usage des base de données en général.

A votre avis, quelle est la relation entre un wiki, un blog et Outlook ? Ce sont toutes des applications qui n’ont absolument pas besoin d’une base de données !

L’usage des bases de données est beaucoup trop systématique. Quand elles sont utilisées à mauvais escient, elles ralentissent considérablement l’exécution de l’application et rallongent de la même manière le temps de développement.

Je me rappelle encore de l’époque de Java 1.2 où les débats entre Java et C++ tournaient toujours en faveur du C++ pour des raisons de performance : "Java ne prendra jamais, c’est un langage interprété, il aura toujours des problèmes de lenteur insoluble". Et ces mêmes personnes de se lancer dans un développement n-tiers en C++ avec une bonne vielle base relationnelle et son langage SQL (interprété) ! Je vous laisse deviner... Ils avaient des problèmes de performance. Je me souviens d’un retour du type : "Nous avons eu des soucis de performance lors de la validation. Cela nous a coûté sacrément cher de corriger ces problèmes, mais nous sommes fiers de toutes les optimisations que nous avons pu mettre en place."

Et de nos jours avec les architectures J2EE multicouches d’une complexité sans pareil, fruits de nombreuses années de standardisation ! N’allez pas parler à une cellule d’architecture d’une solution sans base de données ! Ils ne comprendront même pas les mots.

Questions :
- A-t-on vraiment besoin de persistance ?
- A-t-on une problématique d’accès concurrents aux données ?
- Est-on dans un environnement multi-utilisateurs concurrents ?
- La performance est-elle prépondérante ?

Il est parfois plus judicieux de s’orienter vers une solution à base de fichiers avec un chargement des données en mémoire. Surtout que de nos jours la mémoire est disponible à foison. Avez vous souvent plus de 1Go de données "vivantes" dans votre base ?

Qu’en pensez vous ?

Pour partager nos réflexions sur ce sujet, je vous propose une carte euristique sur mindmeister (Vous pouvez éditer, mot de passe : overkill)

3 Messages de forum

  • Databases overkill ! 2 décembre 2008 20:59, par Bernard Notarianni

    Etienne,

    Je suis totalement et entièrement d’accord avec toi :-) Très beau post et je trouve l’idée du mindmap excellente. Merci pour cette initiative.

    Répondre à ce message

  • Enfin ! 3 décembre 2008 14:14, par Eric

    Ca y est, tu as écrit le post que j’attendais ;-) Mon problème : j’entends déjà les traditionnalistes sortir des arguments du type "oui, mais si je veux y accéder à partir d’un autre système ? et si je veux persister ? et si j’ai un crash système ?" etc.

    Tu devrais faire un autre post sur les cas où tu as pu remplacer une BDD par de la RAM. Et aussi les cas où tu as pu trouver des solutions à certains besoins spécifiques, du style de ceux mentionner ci-dessus.

    Répondre à ce message

    • Enfin ! 3 décembre 2008 22:28, par Etienne Charignon

      > oui, mais si je veux y accéder à partir d’un autre système ?

      C’est le point justement traité par Martin Fowler dans son post. Je t’y renvoie.

      > Si je veux persister ? Si j’ai un crash système ?

      Si tu veux persister, alors, il faut trouver un moyen d’écrire les données sur un support de masse ! :-) Est-ce que les bases de données sont le seul outil ? Est-ce vraiment une idée "simple" d’écrire les données dans une base de données relationnelle au travers d’un ORM ? En fait, c’est tellement tordu que c’est à se demander comment ça peut marcher. Enfin, avec beaucoup d’effort on y arrive.

      Je travaille actuellement sur un site web me demandant de permettre à des utilisateurs de soumettre des fichiers puis de les reprendre... Pour certains utilisateurs, il faut pouvoir obtenir une version consolidée de plusieurs fichiers. Les utilisateurs ne peuvent pas voir les fichiers des autres (sauf pour ceux qui peuvent voir les consolidations évidement) Mais que vient faire une base de donnée dans tout ça ? Où est le risque de crash système ? Si le fichier n’a pu être enregistré, il suffit à l’utilisateur de le soumettre à nouveau. Si on a peur du crash, il faut alors mettre en place des algos de signature à base de CRC. Même les bases ne sont pas protégées contre les erreurs d’écriture. La preuve sur le système de ce site (SPIP) ou je suis obligé d’aller régulièrement demander à mysql de se "réparer" !

      > Tu devrais faire un autre post sur les cas où tu as pu remplacer une BDD par de la RAM.

      J’ai travaillé sur une application chargée de manipuler des données sensibles, il ne fallait rien écrire sur le disque dur sous peine de se voir obligé de développer des algorithmes d’effacement sécurisé. Cela n’avait pas empêché l’architecte de préconiser une base de données (heureusement, nous n’avons pas suivi sa recommandation).

      J’ai travaillé sur un ETL. Mais quel est le c.. qui veut utiliser une base de données dans un ETL ? Nous manipulions les données en mémoire, jusqu’à 3 Go (c’est la limite de windows 32 bits). 3Go, ça donne énormément de latitude pour choisir le moment où on décide d’écrire sur le disque.

      J’ai travaillé sur un système de configuration d’un réseau UMTS. La configuration représente un réseau de plusieurs milliers de nœuds de plusieurs millions de paramètres. Cela représentait des fichiers XML de 150 ou 200 Mo. Aucun problème pour travailler en mémoire. Sauvegarder un tel fichier prend moins d’une minute.

      Répondre à ce message

SPIP | squelette | | Plan du site | Suivre la vie du site RSS 2.0