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
Source : http://www.php-experts.org