Home > MySQL > Les bases de données épaisses

Les bases de données épaisses

Frédéric Brouard a lancé un pavé dans la marre du développement en expliquant le concept de “bases de données épaisses“. Il va même plus loin en affirmant que ce mode de développement peut assassiner les ORM et les FrameWorks.

Pour rappel, l’ORM (pour “Object-Relational Mapping“) vise à faire correspondre un objet de la couche applicative aux données qu’il exploite dans la base de données. En quelque sorte, on a donc une “base de données orientée objet” puisque, pour faire très simple, chaque champ de la base peut être une propriété d’un objet. Mais selon Frédéric Brouard, le concept mérite qu’on s’y attarde et qu’on le développe.

Dans un applicatif exploitant une base de données épaisse, ce n’est ni le client ni le serveur web qui doivent réaliser le maximum des opérations nécessaires, mais bel et bien la base de données. Outre le fait qu’on obtient une application plus facilement portable (puisque le PHP ne ferait plus ou moins que de l’affichage), on supprime aussi un goulot d’étranglement important en éliminant les aller/retour incessants entre l’applicatif et la base.

Pour prendre un exemple simple, quand on veut calculer une moyenne, on ne rapatrie pas l’ensemble des lignes à prendre en compte avant de faire un calcul à la main, on utilise plutot la fonction AVG() qui exécute le traitement nécessaire et ne renvoie qu’un résultat final.

Avec une base de données épaisse, en utilisant notamment des requêtes SQL avancées, les procédures stockées, et pourquoi pas des User-Defined Functions (UDF) sous MySQL, on peut arriver au même résultat avec la majorité des traitements que nécessitent une application.

En déportant son code métier vers la base de donnée quand cela est possible, non seulement on décharge les serveurs frontaux, mais on améliore aussi la circulation des données dans l’ensemble de l’architecture, puisqu’on ne rapatrie à aucun moment de gros resultsets uniquement pour les traiter. Les liens entre base de donnée et applicatifs sont ainsi préservés.

La base se retrouve donc avec plus d’opérations à réaliser, mais il faut bien le reconnaître: sur un site à fort trafic, à moins qu’on aie beaucoup d’écritures à réaliser, c’est rarement la base – même avec un certain volume d’informations – qui représente le goulot d’étranglement le plus étroit. C’est souvent plutôt le serveur Web et la couche réseau en général qui saturent (J’ai plus souvent vu 1 BDD + 3 Apache en front que le contraire…).

Du coup, le principe d’ORM peut être tué, mais aussi sublimé: une base de données épaisse pourra ne pas embarquer que la partie “stockage” d’un objet (propriétés) mais aussi sa partie “métier” (méthodes). Et si possible, tout le reste, et en restant basé sur du relationnel, donc sans avoir à quitter son SGBDR favori ;)

Liens

Le Monde Informatique : Les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse ?
Frédéric Brouard, alias SQLPro sur Développez.com

Ce post vous a été utile ? Re-Twittez le ! ReTwittez ce post

MySQL ,

  1. | #1

    C’est bien sur évident du point de vue de la performance et pas nouveau du tout. Ca marche bien pour des traitements simple faisable dans le SELECT de la requete.

    Par contre, disperser plus sa logique métier est contre productif selon moi : http://www.glagla.org/weblog/2007/05/16/trigger-ou-pas-trigger/

  2. Mat
    | #2

    Personnellement, je préfère déporter la majeur partie des calculs sur la partie web/front que sur la base de donnée.

    Il est bien plus facile de rendre scalable un serveur web (en faisant un cluster load-balancé) plutot qu’une base de données (sharding, réplication avec read/write balancing, quoi qu’il arrive il y a un gros travail à effectuer coté applicatif).

  3. | #3

    Je suis 100% d’accord! Les développeurs ont souvent la mauvaise habitude de tout centraliser au niveau du code. Résultat: un serveur web abusivement sollicité et un serveur MySQL idle.

    Il faut savoir répartir équitablement la charge, et dans quelle circonstance il est préférable de le faire. Non seulement on y gagne en performance, mais aussi une validation d’intégrité quant à la logique métier à respecter.

    Je trouve un peu exagéré de “tuer” les ORM. Ils sont bien et ils accélèrent le développement d’une application, mais il faut bien comprendre les limites! Ils ne sont pas conçus par exemple pour produire un rapport financier qui doit agréger plusieurs données.

  4. | #4

    “Outre le fait qu’on obtient une application plus facilement portable”

    Ah ? parce que maintenant les procédures stockées sont portables d’un SGBDR à l’autre (enfin… pour ceux qui les supportent !) d’un claquement de doigt ?

  5. | #5

    Merci de m’avoir signalé cet excellent article de Frédéric Brouard. Un de ses mérites est de mettre en évidence le fossé entre les développeurs qui ont une culture du développement web et ceux de l’”industrie”. Pour les seconds, la question de la portabilité de la base de donnée ne se pose pas. Il n’existe qu’un très petit nombre de SGBD “sérieux”, et le choix de l’un d’eux par une entreprise est un des fondements les plus intangibles de sa culture informatique. Chez Machin, on utilise Oracle depuis toujours et personne n’imagine une seconde utiliser une autre base. La base change moins vite que les langages utilisés pour réaliser les interfaces. Dès lors, il est naturel d’exploiter au maximum les possibilités du SGBD. De l’autre côté, dans le monde du web, beaucoup de développeurs ne connaissent que des outils “gadget”, comme PHP et MySQL. Vu les faibles possibilités de ce dernier, on a pris l’habitude de ne considérer les bases de données que comme de simples entrepôts de stockage, interchangeables.

    Il y a là deux cultures très éloignées. Mais je ne crois pas que l’une ou l’autre l’emporte un jour. Elles ne jouent pas dans la même cours de récréation. La majorité des applications web sont de toute façon des trucs jetables pour lesquels il n’est pas nécessaire d’investir en développements sérieux.

  6. Hawat
    | #6

    Le “concept” de “bases de données épaisses” est proprement idiot.
    Il va a l’encontre de maints principes fondamentaux de developpements propre et moderne.

    Bien entendu, pour certains cas particulies ou meme pour un jeune developeur naif ca pourrait paretre allechant.

    Par “naif”, il faut entendre sans comprehension profonde des modeles existants.
    Cela ne sous entends pas, par exemple, comprendre le fonctionnement de MVC/MVC2 mais plutot pourquoi nous en sommes arrive a ces conclusions.
    Sinon vous vous condamnez a repasser par les chemins qui ont ammene la.

    Le modele de developpement en couches a une raison d’etre autre que theorique!

    La “bases de données épaisses” va a l’encontre meme du principe de separation des roles.
    Un projet empruntant ce chemin, sur le long terme, arrivera sans l’ombre d’un doute a un spagetti difficilement maintenable et/ou evolutif.

  7. Mazzu
    | #7

    Quelqu’un connaitrait il le nom anglais du concept de base de données épaisses ?

  1. No trackbacks yet.