On est en 1995. Apparaît "The Third Manifesto" (devenu "Databases, Types and the Relational Model", prémière édition en 1998, 3eme en 2007).
Au départ c'est un article scientifique. Les auteurs, C.J. Date et Hugh Darwen, répondent à deux manifestes précédents :
- 1989 - Malcolm Atkinson - The Object-Oriented Database System Manifesto
- 1990 - Michael Stonebraker - Third Generation Database System Manifesto
Ces manifestes successifs naissent à la croisée des chemins. Deux champs de recherche qui s'ignorent pour l'essentiel s'entrechoquent d'un seul coup:
-
Entre 1960 et 1980, côté DB et programmation business, on s'occupe de la manière dont les données sont conservées et optimisées sur disque, d'indépendance entre couche applicative et persistence, de cohérence, de transactions, de langages d'interrogation, de reprise sur incident.
-
Les mêmes années, côté programmation scientifique et système, on monte le niveau d'abstraction. On dépasse les seuls nombres, chaînes de caractères, espaces mémoire et pointeurs disponibles dans des langages bas niveau. Naissent alors les Abstract Data Types et les Classes & Objets, le data hiding (Parnas, et Liskov avec Simula), le message passing (Alan Kay avec Smalltalk), etc.
Une petite décénnie plus tard, BOUM. Les développeurs se plaignent: fichiers et bases de données sont bien incapables de supporter la richesse de ces nouvelles structures d'objets qui tiennent pourtant si bien en mémoire. Les deux premiers manifestes naissent coup sur coup: on veut des DB orientées objet, pas de ce SQL (qui s'est pourtant largement installé pour détrôner COBOL).
Sauf que s'entremèlent dans ces manifestes d'une part des plaintes légitimes envers SQL (dont le design est pourri), d'autre part une incompréhension manifeste du travail théorique des vingt années précédentes côté DB. En particulier une exécrable compréhension du modèle relationnel. Il a pourtant une base mathématique très solide, lui, alors que les challengers n'en ont pour ainsi dire aucune.
Ce sera brillamment démontré par Date & Darwen dans leur troisième manifeste, et l'excellent livre qui suivra où ils en profiteront pour redocumenter le modèle relationnel avec grande rigueur et beaucoup de recul. Eux aussi critiquent SQL, peut-être plus fort encore. Mais en même temps ils insistent: on ne saurait considérer sérieusement des propositions venant de langages de programmation qui confondent allègrement valeur (par nature immutable), variable (qui change avec le temps), type (un ensemble de valeurs), classe (on ne sait pas trop ce que c'est en vrai), réprésentations, pointeurs, etc.
Leur diagnostic est clair: aucune chance de détrôner le modèle relationnel - malgré toute les faiblesses de SQL - avec des propositions construites sur du sable sur le plan théorique. C'est SQL qui a détrôné COBOL, pas l'inverse.
L'histoire leur donnera raison : les bases de données objets s'installeront de manière anecdotique dans des secteurs niche. PHP/MySQL et les ORMs leur donneront le coup de grâce moins d'une décénie plus tard. SQL est toujours là. NoSQL aura une ambition similaire vers 2010, détrôner SQL, et un raté tout aussi retentissant. SQL est toujours là.
Les fins connaisseurs du Troisième Manifeste attendent toujours un challenger qui ait prit la peine de lire et comprendre les arguments de Date et Darwen - et au passage, leur travail de recherche remarquable pour affiner et moderniser le modèle relationnel sur le plan théorique. En vain jusqu'ici. Chaque décénnie les chiens aboient, chaque décénnie la caravane passe, et SQL reste.
Pour ma part, je pense que c'est d'une autre croisée des chemins que viendra la solution. Date & Darwen ont largement démontré qu'au coeur du conflit se cache une question de type system. Les langages purement fonctionnels ont deux choses théoriquement correctes que l'orienté objet n'a pas: l'immutabilité - donc la notion de valeur essentielle en DB - et une théorie des types qui est à la fois très riche et très solide.
Plus qu'à attendre quelques caravanes encore.
#SQL #Databases #SoftwareEngineering #History