Les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse ?
juin 22, 2009 3:11 Architecture & Développement, Systèmes d'informationTribune de Frédéric Brouard, spécialiste en bases de données relationnelles, enseignant au Cnam, à l’école d’ingénieurs Isen de Toulon et conférencier à l’Université de Toulouse le Mirail. Frédéric Brouard est aussi l’auteur du site sqlpro.developpez.com.
Pour un meilleur confort de lecture, nous reproduisons ci-dessous le début du texte, et nous vous invitons à télécharger la version intégrale (15 pages) en PDF.
Darwinisme et informatique : les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse ?
Dans l’histoire de l’informatique il y a un certain nombre de théories et concepts sur lesquels tous les professionnels s’accordent. Il en est ainsi de la théorie de l’information de Claude Shannon, de la théorie des langages (Turing, Chomsky…) et de la théorie des bases de données relationnelles d’Edgar Codd. Sur le reste, les avis vont du consensus mou (par exemple l’intérêt des langages orientés objets) à la divergence la plus absolue (comme où placer le code métier)… C’est un concentré de tous ces sujets que nous allons aborder…
1 - Histoire des bases de données
Si aujourd’hui on s’accorde de fait sur l’utilisation assez systématique des bases de données relationnelles, cela n’a pas été sans mal. Les ancêtres des SGBD relationnels organisaient les données dans des espaces physiques fortement redondants constitués par des bases de données hiérarchiques. Puis vinrent les bases de données dites “réseau” dont la redondance était mieux maîtrisée mais dont l’organisation du stockage reposait toujours sur des fichiers, à raison d’un fichier par “article”, c’est à dire par entité dont on souhaite conserver les informations.
Les inconvénients majeurs de ces différents systèmes, notamment celles tournant autours des aspects physique de l’organisation des données posaient de multiples problèmes : difficulté de modification de la structure des fichiers en cas d’évolution du modèle, repérage de l’information par le biais d’une référence physique à la ligne dans le fichier (enregistrement), typage insuffisant. Ces impasses conduisirent Edgar Codd à trouver une solution basée sur l’ajout d’une couche logique permettant de se rendre indépendant de toute problématique physique. Mais le trait de génie d’Edgar Codd fut de considérer les données comme ensemblistes, c’est à dire n’ayant aucune relation d’ordre interne. Chris Date donna à juste titre le mot de “sac” (bag) aux relations comme analogie, et c’est à l’évidence le mot le plus juste. Il n’est qu’à regarder le contenu du sac à main d’une femme pour se rendre compte qu’il n’y a vraiment aucun ordre là -dedans 
Dans les années 80, la mode des concepts objets, introduits par les travaux de Barbara Liskov et popularisés par les méthodes de Grady Booch, fait fureur. On voit arriver des langages purement objet comme SmallTalk. Plus réalistes les éditeurs comme les utilisateurs leurs préféreront des langages hybrides à base de programmation impérative ajoutant la puissance de l’objet. On en arrive aux langages orientés objets modernes que l’on connaît aujourd’hui (Java, C++, C#…).
Dans le même temps, des essais plus laborieux ont lieu afin de rendre les bases de données purement objet. Hélas, il n’existe presque plus aucune trace de ces outils dont les noms ont fortement résonné sur les bancs des universités : O², Orion, GBase, VBase, Iris, GemStone… Seul véritable survivant, l’éditeur Versant a réussi à en racheter quelques-uns tandis qu’Objectivity et Caché constituent des outsiders épars. En bref, la quasi disparition de ces dinosaures n’est pas due à un cataclysme, mais plutôt à la sélection naturelle :
- les bases de données relationnelles étaient déjà matures et performantes, ce qui était loin d’être le cas des bases de données objet;
- le volume des données déjà stockées en relationnel constituait une forte inertie pour passer aux bases de données objet.
Les aspects de complexité rajoutée et la faible utilisation en pratique des techniques purement objet inhérentes à ces types de bases rendaient dubitatifs les développeurs et couteux les développements;
l’absence d’une théorie mathématique fiable sous-jacente aux bases de données objet leur interdisait toute interopérabilité naturelle.
Tant et si bien que, de la même façon que les langages purement objet comme Smalltalk ont opéré une mutation au profit de langages hybrides fortement teintés d’objet, les bases de données relationnelles faisaient la révolution opposée en introduisant des concepts objets en leur sein. Le monde des éditeurs de SGBDR s’accorda donc autour d’une norme (SQL:1999) et aujourd’hui les SGBDR modernes comme Oracle, IBM DB2 ou SQL Server permettent de manipuler des objets au sein des tables d’une manière simple et somme toute assez efficace, pourvu que ce ne soit pas là l’essentiel des données stockées.
Force est de conclure que le monde des données est encore fortement relationnel, tandis que le monde des programmes est déjà fortement objet…
De là naît une dichotomie qui a eu lieu depuis les premiers temps de l’informatique entre les données et les programmes. Cette dichotomie induit depuis des décennies le vieux débat consacré au placement du code métier… et c’est maintenant cet aspect-là des choses que nous allons aborder.
2 - Abord pragmatique
Lorsque, chaque année, je donne mon premier cours sur les techniques des bases de données relationnelles, je pose à mes étudiants la question suivante : “vous êtes un PDG et je suis un terroriste. Je vous donne le choix suivant : soit je détruis toutes vos machines et logiciels et préserve vos données, soit je détruis toutes vos données et les sauvegardes qui vont avec, et vous laisse vos machines et logiciels. Que choisissez-vous ?”
La plupart de mes élèves s’avèrent judicieux dans leurs choix en préservant les données. Mais sont-ils de bons PDG ? On peut en douter ! En effet, la lecture du bilan d’une entreprise ne laisse aucun doute à ce sujet : on y trouvera de nombreuses lignes comptables sur l’acquisition ou la location des machines et logiciels, comme sur les salaires des développeurs ou des administrateurs. Y voyez-vous une quelconque valorisation des données ? Pour autant, nous savons tous que le capital informatique d’une entreprise est pour l’essentiel constitué par les données. Or que faites-vous pour le préserver, l’améliorer ou l’enrichir ? Avez-vous déjà mis en place un programme de gestion de la qualité ? Avez-vous pensé à établir un plan préventif de gestion de la performance ? Où se trouve la documentation d’accès aux données ?
On constate donc souvent que ces concepts sont oubliés. Mais quelle en est la raison ?
C’est en revenant sur la dichotomie données/programme que l’on peut comprendre le problème : à l’évidence, la différence essentielle qui réside entre les problématiques de données et celles de codage sont les suivantes :
- un manque de connaissance des problématiques de données dans les programmes d’éducation et de formation à l’informatique;
- l’aspect non ludique des données alors que le codage des IHM consacre la cosmétique avec aujourd’hui force strass et paillettes (Html, Flash, 3D…);
- la difficulté de mesurer la production en matière de données6 alors qu’avec le code c’est si simple (autrefois certains informaticiens étaient payés à la ligne de code !).
Tout ceci a conduit la très grande majorité des informaticiens à une fâcheuse inculture du monde des bases de données. Un petit test révélateur fera l’affaire. Posez autour de vous la question suivante : une vue SQL peut-elle être mise à jour à l’aide d’instructions INSERT, UPDATE ou DELETE ? Vous verrez que le taux de réponse est très largement en faveur du non, alors que la solution est oui !
Comment dès lors faire confiance à l’informaticien moyen pour qu’il distille les meilleurs conseils, s’il ne connaît – espérons-le bien – qu’une seule des facettes du monde auquel il a affaire ?
C’est pourquoi la majorité des informaticiens considèrent uniquement l’aspect stockage d’une base de données au détriment des aspects de codage que sont les fonctions, procédures et déclencheurs. Constat d’autant plus vrai que certains produits populaires ayant vu le jour assez récemment (à l’échelle de l’histoire de l’informatique) étaient originellement fonctionnellement si pauvres que les techniques les plus intéressantes n’y étaient pas implantées. Donnons à titre d’exemple MySQL, mais c’est toujours le cas de certains pseudos SGBDR comme SQL Lite…
A la fin de mes premières sessions de cours sur les bases de données, et au vu de mes démonstrations, mes étudiants de cinquième année – ils seront ingénieurs dans quelques mois – sont stupéfaits de constater ce que peut faire un SGBDR moderne. On ne pensait pas qu’on pouvait faire tout cela avec un SGBDR ! Disent-ils en chÅ“ur… Que d’années perdues !
3 - Où placer le code métier ?
Maintenant que nous savons que la base de données est bien plus intelligente que nous le pensions, voyons comment aborder ce vieux débat où les avis divergent. Soyons encore une fois pragmatiques et n’hésitons pas à expérimenter la chose.
Considérons une application Web utilisant un SGBD relationnel de haut niveau permettant d’utiliser toutes les techniques modernes. Ajoutons autant de serveurs que nous voulons…
Dans une telle configuration, on peut répartir le code en au moins trois endroits : sur le client, sur le SGBDR et enfin sur tous les serveurs intermédiaires entre les données et le client. Qu’il y ait, un, deux ou trois serveurs intermédiaires – que nous appellerons tiers – n’apporte aucun changement majeur, dans le sens où nous espérons que chacun des serveurs s’est spécialisé dans une tâche et que le développeur a bien fait son travail (par exemple serveur d’objet “métier” COM, DCOM, CORBA, EJB, .net, serveur de présentation pour le rendu Web, serveur d’application à distance…).
Donc le problème revient à analyser l’importance du code à mettre en Å“uvre aux trois points du système : un client léger ou lourd, un serveur de bases de données épais ou fin et un serveur tiers chargé ou dépouillé.
C’est ce que vient de faire Toon Koppelaars dans un article fort intéressant. Monsieur Koppelaars est un expert en bases de données relationnelles et plus précisément un spécialiste d’Oracle. Il a maintenant sa propre entreprise et a publié en tant que coauteur en 2007 un ouvrage fort intéressant sur le développement en matière de bases de données, avec une approche mathématique de la chose.
Dans cette étude il nous montre qu’en fait il n’existe que sept alternatives au placement du code que voici résumées dans le présent tableau :
Nous avons bien dit sept car la dernière ligne (ligne 8 ) est irréaliste puisque dans ce cas nous supposons pratiquement qu’aucun codage n’est possible sur aucun des systèmes…
L’approche conventionnelle nous indique que la solution la plus souvent retenue est la ligne 6, celle dans laquelle le client est léger, la base n’assure que le stockage et l’interrogation des données et que toute la logique métier est exécutée par le ou les serveurs tiers.
Ce n’est bien entendu pas la réponse la plus intéressante en terme de performances ni de souplesse de développement. Je vous laisse lire les arguments de Toon Koopelars sur la solution préférée (ligne 7), c’est-à -dire le développement épais côté base de données avec des clients et serveurs tiers les plus fins possibles.
L’intégralité de la tribune de Frédéric Brouard est à télécharger en PDF.
juin 24th, 2009 at 16:06
Effectivement .
La majorité des développeurs actuels
1) ne sauraient pas organiser une BD transactionnelle, donc manque de compétence pour organiser une BD relationnelle
2)ne connaissent pas un langage de programmation de type C donc la structure sous-jacente des données.
Résultats des courses (1 + 2 ) :
La majorité des organisations des BD
peuvent être qualifiées de “grotesques” .
Le seul remède utilisé est d’augmenter la vitesse des disques, et les capacités de traitements des serveurs.
juin 25th, 2009 at 21:01
Point de vue original, qui va effectivement à l’encontre de tout ce qu’on a entendu ces dernières années. On pourrait même ajouter, pour abonder dans le sens de l’auteur, que la tendance à déployer des BRMS (gestionnaires de règles métier) permet d’opérer un vrai distinguo entre le code technique, qui peut effectivement se situer avantageusement dans la base, et le paramétrage métier, qui sert véritablement à exprimer le savoir-faire des gens du business.
Toutefois, cela est vu par le prisme d’un formateur en SQL, qui prêche pour sa paroisse. Et quelque soit la beauté d’une technique, ce seront au final les compétences disponibles sur le marché qui feront la différence. En l’occurrence, même si c’est moins efficace, ce sera donc le développement en Java qui l’emportera sur le développement en SQL…
juin 26th, 2009 at 12:59
Quelques témoignages depuis la publication :
***
De sylvain D. :
”
Votre point de vue rejoint celui de nombreux experts en SGBDR et notamment
un certain Tom Kyte, spécialiste Oracle dont le livre “Effective Oracle by
Design” est pour moi une référence!
Je vous recommande la lecture du chapitre 1 qui est général et va même
un peu plus loin que votre plaidoyer en mettant également en défaut de
nombreux préjugés sur l’abstraction de la base de données, les modèles
de données génériques, etc.
Ce chapitre est consultable sur :
http://www.mhprofessional.com/downloads/products/0072230657/0072230657_ch01.pdf
”
***
De Michel P. :
”
Si globalement je suis en plein accord avec ce qui est écrit, il me semble que tu as péché à vouloir gagner la bataille des clochers.
[...]
Voici quelques objections/réflexions à ce discours :
1- Non, le monde de la base de données n’est pas réduite aux seuls traitements transactionnels !
2- La redondance est un sujet épineux. Surtout si on prône son éradication => comment positionner les index, les vues indexées, les data marts, les cubes … dans ce discours ?
3- Les triggers et autres procédures ne sont pas écrites qu’en SQL. On a nécessité d’utiliser des langage de 3ieme génération. Ils ne sont donc pas si mauvais que ça !!!
4- Xml est une structure hiérarchique. Donc non vectorisée. Donc n’a rien à faire dans le mode d’organisation que tu défends !
5- Présenter l’optimiseur comme étant effectivement un sélecteur d’algorithme sans faille est « border line » … Je n’imagine même pas que tu ne connaisses pas de contre exemple => mauvaise foi
Rq : comment repère t’on le choix de l’algorithme de tri qu’a retenu l’optimiser ?? (faudrait peut être changer le mot algorithme par « chemin de traitement » ou qque chose du genre )
6- Chercher à minimiser la forme (et la mise en forme) au profit du fond est un discours … philosophique (Platon nomme Forme (traduction de εἶδος et de ἰδÎα, également traduits par Idée #Wikipedia).
NB : Nous faisons parti du « service » informatique.
De guillaume E. :
”
J’ai lu avec ravissement votre article [...]
Je vous avoue que cela fait du bien de ne plus se sentir seul au monde…
En effet, je fais les mêmes constats que vous depuis des années et me
suis également lancé sur les services autour des bases de données sur Strasbourg depuis peu (www.sqldata.fr).
“
juin 29th, 2009 at 11:45
Si les développeurs ne savent pas “gérer” une base de données, ce n’est pas de uniquement leur faute et par manque de compétences, il y a des DBAs pour cela.
Mais voila, la ou le bas blesse, c’est que des DBAs, il y en a de moins en moins. Et l’origine de ce manque provient des éditeurs eux-mêmes et de leurs slogans de ventes. Rappelez-vous il y a quelques années, lorsque Oracle a sorti la version 10g. “La base s’auto-tune”, ou encore “la base s’auto-administre”… comme si c’était une base artificiellement intelligente.
Le problème, c’est qu’a force de le dire et de le répéter certains ont fini par y croire. 1. les chef de projet ne virent plus l’utilité d’avoir un DBA (qui coûte et ne développe rien), 2. les nouveaux actifs ne furent absolument pas motives par cette branches (DBA) qui fit archaïques et complètement dépasses comparativement a toutes les nouvelles techno bien plus « sexy ».
Alors maintenant, c’est vrai, lorsque la base est trop lente (pour une raison ou une autre), personne ne sait plus faire, et la les SSD (ou autre hardware ultra-rapide) arrivent a point nommes pour sauver la mise. Et rien sur le soft et/ou l’organisation de la base qui ressemble de plus en plus au “sac de madame” (pour reprendre l’exemple de l’article), et c’est bien dommage, parce que ça peut être moins cher, et surtout pour une période peut-être plus longue.
C’est un peu comme la dette publique, on augmente les prélèvements pour compenser l’incapacité à la réduire.
juin 30th, 2009 at 19:16
Article fort interessant et en tout cas educatif pour ceux qui n’avait pas encore realisé l’importance du SGBDR au sein de tout developement qui se respecte.
Nous le faisons depuis bientot 20 ans.
Bien sur en y integrant au fil des ans les innovations. En effet les fonctions et autres existent depuis Oracle 7 uniquement … ne parlons pas de SQL Server qui n’existait probablement pas encore.
;o)
Mais cela dit, il faut un dosage selon les cas et abuser de la base peut rendre sa gestion complexe et pose le probleme de limite de responsabilite du DBA.
La ou je suis pas tout a fait d’accord c’est au niveau de votre opinion sur les ORM. Celle-ci aurait ete vrai il y a peu mais ne l’ai plus trop.
Pour moi, l’ORM doit rester au niveau des serveurs d’application.
C’est d’autant plus vrai que cela permet une architecture plus securisé en permettant une securite a plusieurs niveaux sur les objets business et les donnees qu’elles representent.
D’autre part, les framework .net et j2ee ont des fondations extremement solides pour l’avenir.
Jetez un coup d’oeil au framework MVC d’Oracle (ADF 11g) et vous comprendrez qu’on evolue vers du vrai RAD qui nous evite de se soucier d’ORM, d’Ajax et autres composantes qui permettent de constuire les clients de demain.
Flex, Javascript, Groovy etc.. ne servant qu’a l’habillage et donc leur risque de se demoder devient non critique.
Hier on ne se souciait pas de quoi etait fait les outils RAD client/serveur comme Oracle Forms, Uniface et autres et c’est ce qui faisait de ces produits des outils RAD.
Ce serait bien que ce soit de meme pour les outils RAD de demain.
juillet 25th, 2009 at 11:06
Très intéressant article et si je suis assez d’accord sur la conclusion en théorie, je suis plus dubitatif sur la pratique.
Je n’ai pas de formation mathématique poussée et ne suis pas un gourou de l’architecture, je me contenterai donc d’un constat de terrain après 10 ans passés en sociétés de services.
J’ai participé à un projet dont l’architecture imposait à chaque étape de traitement métier, d’externaliser les données de la base pour les faire traiter par un ETL, sous le prétexte que celui ci accédait plus rapidement à de fichiers plats qu’à la base (Oracle). A la fin du traitement, intégration des fichiers plats générés par l’ETL dans la base.
Et rebelote à chaque étape fonctionnelle.
Quand on joue à ce jeu avec 60 Go de données et plus, les temps de traitement s’allongent…jusqu’à devenir insupportables (> 8h), même avec de gros serveurs.
Il y aurait eu ici un vrai intérêt technique à ramener les traitements à l’intérieur de la base de données.
Dans un autre projet, l’utilisation de l’ETLétait obligatoire… pour amortir l’architecture de grid computing mis en place dans l’entreprise!
Tant il est vrai que les décisions techniques sont parfois prises sur des bases discutables.
Mais il y a surtout plusieurs arguments à mon sens qui rendent difficile cette internalisation des traitements métier :
- tout d’abord, je suis d’accord avec Nicolas Gasparotto, il y a pénurie de compétences et le phénomène ne se limite pas aux DBA : combien de developpeurs PL/SQL ou Transact-sql connaissent à peine la syntaxe du langage. Et ne parlons pas d’optimisations. Il est maintenant plus simple de trouver sur le marché des compétences sur les ETL par exemple.
- ensuite, je parlerai de ce que je connais le mieux, les librairies PL/SQL standard sont parfois assez rustiques. Réinventer la roue en permanence coûte cher en temps, en fiabilité et limite l’intérêt du travail. Difficile de faire du traitement métier quand des besoins techniques de base (logging, error handling…) ne sont pas bien couverts.
- enfin, osons le dire, les traitements métiers dépendent directement des fonctionnels… qui ne savent pas toujours bien ce qu’ils veulent (et parfois aussi parce qu’ils apprennent leur fonction avec nous) ! La complexité du besoin exprimé provient aussi de la méconnaissance du métier par le demandeur. Et il est souvent perçu comme plus simple par le client de changer “un fil” dans un ETL que de replonger dans le code même si les besoins de tests restent les mêmes ensuite.
Au final, si l’objectif d’effectuer les traitements métiers à l’intérieur de la base est excellent techniquement, les moyens pour y parvenir sont pour l’instant un peu faibles.
Mais l’augmentation exponentielle des volumes de données nous contraindra à trouver rapidement des solutions en gardant les données dans les bases, avec un accès rapide pour leur traitement.
Les ETL perçus par beaucoup de clients comme la panacée, sont apparus à un moment où les volumes de données étaint moindre qu’aujourd’hui.
Pour les avoir utilisés ces dernières années leur intérêt me semble décroissant actuellement.
Ils sont :
- riches,
- mais mal optimisés en accès (à vouloir être universels),
- et lourds à utiliser (allez donc “tirez les fils” quand vous avez 400 colonnes à distribuer entre les divers traitements comme je l’ai vu),
leur salut résidera peut être dans leur fusion avec la base de donnée, ce qui nous donnera …des bases de données épaisses.
Nb: Je consacre actuellement un blog aux Frameworks PL/SQL (http://plsqlframework.blogspot.com/) et je souhaiterais obtenir l’autorisation de l’auteur et du Monde Informatique pour traduire ce texte en anglais et l’utiliser comme support de débat sur mon blog. Frédéric Brouard et LMI pourraient-ils me donner leur position à ce sujet ? Par avance, merci.
juillet 26th, 2009 at 15:05
Bonjour,
J’aurais du préciser sur mon post précédent que je souhaitais étendre le concept de base de donnée épaisse de votre article du domaine interactif au domaine batch et aux ETL.
Car la même question se pose pour les ETL quand on voit leur mise en oeuvre actuelle.
En effet, les accès interactifs et les accès batch ont un même point critique :
un temps limité, même si les volumes de données traités et les contraintes d’architecture sont très différents dans les deux cas.
Et le concept de base de donnée épaisse me semble tout aussi intéressant dans le cas des ETL.
Quand à ma conclusion sur le salut des ETL, en les privant de leur E et de leur L, il aurait mérité un smiley final
Pardon d’être un peu long, mais le sujet me passionne vraiment!
juillet 27th, 2009 at 9:49
Bonjour M. Rigaïl,
pas de souci de notre côté, pourvu que vous laissiez une mention de la source et le lien vers le billet original en français.
Merci de votre intérêt,
Olivier Rafal
Rédacteur en chef LeMondeInformatique.fr
septembre 11th, 2009 at 0:21
[...] différentes tables, vous allez vite vous retrouver avec des données orphelines. Si le concept de bases de données épaisses essaye d’éviter cela, cela ne change rien au problème fondamental, qui est que ces [...]
octobre 19th, 2009 at 17:52
Sur le fond, Frédéric Brouard a raison: il est plus efficace de co-localiser données et traitements.
Mais la base de données épaisse n’est pas la seule réponse possible !
C’est pourquoi, dans le monde Java, on a vu apparaitre des solutions de caches distribuées, puis de NAM (Network-Attached Memory) puis de data grid (correspondant à des solutions comme Terracotta ou Oracle Coherence). Une data grid, c’est une sorte de base de données objet déguisée : en effet, une data grid a des capacités transactionnelles (ou tout comme), est capable d’indexer ses données, de les partitionner… de manière similaire à une base de données relationnelle, mais dans le monde Java. Une data grid se place “entre” un serveur d’applications et une base de données généralement relationnelle.
C’est une solution alternative aux bases de données épaisses.
Quoiqu’il en soit, la solution proposée par Frédéric Brouard ne manque pas d’intérêt.