Un billet très intéressant. « On passe son temps à basculer du modèle relationnel au modèle objet puis au modèle document et inversement. » C’est effectivement l’un des gros points noirs du développement Web, en particulier.
NoSQL permet de se passer du modèle relationnel et de supprimer une conversion. Mais il y a aussi l’architecture XRX (XForms, REST, XQuery) qui a fait son petit buzz il y a 2 ans et qui permet de travailler avec le modèle arbre/document d’un bout à l’autre. Christian, as-tu des retours d’expériences sur des projets XRX ?
[Reply]
Qques remarques (au risque de me gourrer…).
Oui, je m’étais fait aussi la remarque que le boulot du développeur web était grandement centré autour
– du transvasement des données d’une couche à une autre, avec transformation des formats
– et de la gestion des conteneurs de données des différentes couches (par ex, httpsession), et des caches pour en obtenir les meilleurs perfs.
Par ailleurs, je ne suis pas convaincu (du tout) que le modèle objet soit défini par intension, et le modèle table défini par extension… à vue de nez, je dirais plutôt le contraire… disons, pour faire court, que je peux voir la définition en intension comme un système de liaison différée (~il faut une main invisible pour recoller les bouts). A ce titre, la donnée d’un pointeur est une définition en extension: pas besoin d’une main invisible, il suffit de suivre le pointeur pour retrouver les données référencées/pointées. Par contre, avec une base de données, avec une foreign key, sans moteur de base de données (la main invisible), d’un point de vue centré sur les tables, si je pars d’une table avec une entrée disposant d’une foreign key, je ne peux pas retrouver l’entrée de l’autre table… sans l’aide du moteur de base de données, donc pour moi, c’est une définition en intension.
Quant à écrire : « On comprend aisément la forte contrainte d’intégrité requise pour les bases de données relationnelles : une modification doit se déployer sur l’ensemble du système, de manière extensive, pour en garantir l’intégrité. Avantage à la maîtrise des données mais difficultés à passer à l’échelle du web. » => il est question ici des bases de données relationnelles, mais cette constatation peut s’appliquer à n’importe quel conteneur de données IMHO ; ou dit autrement, le paragraphe cité indique une généralité, donc si je ne remets pas en cause l’existence du dit paragraphe, j’applique cette généralité à tout type de conteneurs (cf. ma remarque), et si l’on rentre dans les détails (par ex, sharding), alors je pense qu’il faut aussi rentrer dans les détails du sharding pour les bases relationnelles, et du coup, le paragraphe cité n’a plus lieu d’être car trop flou…
A propos du Type System, en quoi faire en sorte que, la fonction ne retourne plus un INT mais à un CHAR, fait que l’on a contourné l’effet de bord ???
Je ne suis pas d’accord avec « POST n’est pas une fonction idempotente (pure) car elle va modifier l’état du système » => un appel POST ou 2 appels POST identiques produise la même modification de données. Donc, je dirais au contraire qu’il y a idempotence (du point de vue fonction).
Je ne suis pas d’accord avec Meijer quant il écrit « Entities have identity » (SQL) et « Environment determines identity (CoSQL) ». Dans les 2 cas, IMHO, « Entities have identity »: pour SQL, les entrées ont une clé (primary key), et pour le CoSQL, pareil, puisque l’on parle ici de clé/valeur ! Si l’on assimile clé & identité pour SQL, je ne vois pas pkoi ce ne serait pas aussi le cas pour le CoSQL.
Quant à ce qui a repoussé les investisseurs approchés par Tim Berners Lee, cela est sans doute moins qu’ils ne comprenaient pas l’intérêt d’un système métastable comme le web, mais plutôt le fait de définir un système ouvert, basé sur des standards, eux-mêmes ouverts.
[Reply]
Christian Reply:
avril 20th, 2011 at 6:06
@ Dominique de Vito :
« je ne suis pas convaincu (du tout) que le modèle objet soit défini par intension, et le modèle table défini par extension… à vue de nez, je dirais plutôt le contraire… »
Je ne te cache pas que j’ai passé 2 heures sur ce point parce que ce n’était pas du tout évident. Dis-toi qu’avec les TABLES, l’identifiant (ici Primary Key) doit être extensivement écrit dans tous les tables. Cela veut dire qu’en voyant une table tu ne peux pas savoir quelles sont les tables qui pointent vers elle (tu ne vois pas la « main invisible » comme c’est le cas avec le modèle Objet-Graphe en utilisant les adresses). Tu vois mieux où pas dit comme çà ?
[Reply]
Christian Reply:
avril 20th, 2011 at 6:13
@ dominique De Vito
A propos du Type System, en quoi faire en sorte que, la fonction ne retourne plus un INT mais à un CHAR, fait que l’on a contourné l’effet de bord ???
Là je me suis trompé, en fait il faut passer à un degré de généralité plus grand. Ce n’est pas passer de INT à CHAR mais de INT à une Collection de INT .
Il faudra que je modifie le texte.
[Reply]
Christian Reply:
avril 20th, 2011 at 6:16
@ Dominique
Je ne suis pas d’accord avec « POST n’est pas une fonction idempotente (pure) car elle va modifier l’état du système » => un appel POST ou 2 appels POST identiques produise la même modification de données. Donc, je dirais au contraire qu’il y a idempotence (du point de vue fonction).
Là, je vais attendre pour répondre à cette question, j’attends d’autres commentaires. Je pense que çà va être intéressant.
[Reply]
Christian Reply:
avril 20th, 2011 at 6:24
@ Dominique
Je ne suis pas d’accord avec « POST n’est pas une fonction idempotente (pure) car elle va modifier l’état du système » => un appel POST ou 2 appels POST identiques produise la même modification de données. Donc, je dirais au contraire qu’il y a idempotence (du point de vue fonction).
Je ne suis pas d’accord avec Meijer quant il écrit « Entities have identity » (SQL) et « Environment determines identity (CoSQL) ». Dans les 2 cas, IMHO, « Entities have identity »: pour SQL, les entrées ont une clé (primary key), et pour le CoSQL, pareil, puisque l’on parle ici de clé/valeur ! Si l’on assimile clé & identité pour SQL, je ne vois pas pkoi ce ne serait pas aussi le cas pour le CoSQL.
C’est un peu le même problème qu’avec la définition par intension et par extension :
Dans un graphe, il y a un des deux noeuds qui ne sait pas que l’autre pointe vers lui (si tu lui pose la question il te répondra qu’il est seul au monde). L’autre, celui qui a un pointeur, connaît l’existence et l’adresse des autres noeuds qui constituent son identité ; de lui-même, il peut retrouver ses petits. Avec SQL les entités *mères* n’ont pas d’adresses vers leurs *fils* ; ici seuls les fils connaissent la mère.
[Reply]
Je reviens à propos du papier de Meijer and co…
Perso, j’ai commencé à lire ce papier, mais je ne l’ai pas encore fini à ce jour.
Bon, Meijer illustre le schéma des données objet et celui des données relationnelles, et indique que les flèches des 2 schémas sont inverses l’une de l’autre. ok.
Ensuite, il introduit les *index* de bases de données. Et c’est peu près que j’ai stoppé la lecture de cet article.
Ceci étant, les flèches des *index* relationels ne sont pas représentées, mais l’eussent-elles été que l’on se serait aperçu que les flèches des index relationnels correspondent aux flèches des données objet.
cf. figure 7 du papier ici http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-model-of-data-for-large-shared-data-banks/fulltext
Perso, je me suis jamais posé de questions précises sur les index de bases de données relationnelles…
Mais si ces index peuvent être bien vus comme des flèches-pointeurs, alors cela me semble ouvrir une perspective car les données relationnelles munies des flèches des index relationnels ressemblent (vu de loin) à l’organisation des données dans une base objet !
Si cette ressemblance est bien effective (à valider), cela veut dire que des données organisées de manière relationnelle peuvent aisément se retrouver (via les index) dans une forme proche de celle des bases de données objet.
Pourrait-on imaginer l’inverse ? Par ex, à partir d’une base de données objet, est-ce qu’avec des index inverses, ne pourrait-on pas rapprocher des données organisées en objet de l’organisation propre à celle d’une base de données relationnelle ?
Et si l’on peut effectivement faire le trajet dans un sens organisation relationnelle=>objet et aussi dans l’autre objet=>relationnelle, quelle valeur donner au discours selon lequel il n’y a que les bases relationnelles et l’organisation relationnelle qui vaillent, et que les bases objet sont une voie de garage ?
C’est troublant cet aperçu détaillé des index relationnels…
[Reply]
Christian Reply:
avril 20th, 2011 at 6:29
@ Dominique :
Mais si ces index peuvent être bien vus comme des flèches-pointeurs, alors cela me semble ouvrir une perspective car les données relationnelles munies des flèches des index relationnels ressemblent (vu de loin) à l’organisation des données dans une base objet !
Exactement. Un index à la forme d’un modèle Objet-Graphe avec stockage clé-valeur. C’est là dessus que se positionne le SEarch Based Application : çà remouline toutes les données de la base relationnelle pour l’exposer en modèle objet-Graphe : tu rajoutes une appli qui requête l’index du moteur de recherche et çà va nettement plus vite.
[Reply]
Le problème du « sens des flèches » est très intéressant. Il se résume à: « Comment figer les relations entre les données sans restreindre ni imposer de cheminements dans ces données ».
Cela a des implications qui dépassent largement le petit monde informatique.
Un article creusant cette question serait peut-être bienvenu?
[Reply]
A propos de l’adéquation naturelle modèle objet/architecture du web:
c’est quelque chose qui saute aux yeux, seule la prépondérance (abusive) du SQL peut expliquer que cette évidence n’ait pas été plus largement reconnue plus tôt.
Pour mémoire, la plateforme ZOPE (voir http://en.wikipedia.org/wiki/Zope ) propose une base de données objet (la ZODB) qui est nativement câblée sur un serveur HTTP fonctionnant comme un broker d’objets, et qui est équipée d’un indexeur d’objets (du genre de Lucene).
Cela en fait un système absolument génial pour le développement web, le détail étonnant étant que cela ait été inventé à la fin des années 1990, que cela continue de s’améliorer depuis, tout en restant assez méconnu.
[Reply]
@Christian
« Ainsi « Idempotence » en REST signifie « Pureté » en langage fonctionnel : la valeur d’une fonction ne change pas dans le temps (pas d’effet de bord). Par où l’on voit que le style d’architecture REST est un style qui s’appuie sur une architecture fonctionnelle pure par défaut : POST n’est pas une fonction idempotente (pure) car elle va modifier l’état du système.. »
@ Dominique
« Je ne suis pas d’accord avec « POST n’est pas une fonction idempotente (pure) car elle va modifier l’état du système » => un appel POST ou 2 appels POST identiques produise la même modification de données. Donc, je dirais au contraire qu’il y a idempotence (du point de vue fonction). »
@Christian
« Là, je vais attendre pour répondre à cette question, j’attends d’autres commentaires. Je pense que çà va être intéressant. »
1ere réaction: doh c’est PUT qui est idempotent pas POST, le b.a.-ba de l’HTTP Restful.
2me lecture: ah oui mais là on fait le parallèle avec la programmation fonctionnelle, et j’ai bien l’impression que l’idempotence n’a pas tout a fait le même sens dans le paragdime REST (qui est un style d’architecture) que dans le paradigme fonctionnel (un style de programmation).
Donc il faudrait définir ce qu’est idempotence du point de vue du paragdime fonctionnel ? Moi ça me dépasse.
Maintenant si on reprend le parallèle PUT/POST. Dans le cas du PUT c’est le client qui décide de tout: contenu de la ressource, URI. Et ce quelque soit l’état des ressources côté serveur, d’où l’idempotence: 2 appels ou + identiques produisent le même effet. Dans le cas d’un POST la modification va dépendre de l’état des ressources coté serveur. Par exemple si j’ai une url qui permet d’effectuer une réservation pour un concert via un POST, deux POST successifs identiques ne vont pas produire le même effet (génération d’un nouveau numéro de réservation, erreur car une même personne n’a pas le droit de faire deux réservations, erreur car il ne reste plus de place lors du 2eme appel,…)
[Reply]
Mince c’est quoi la syntaxe pour faire de jolies citations? Pas de preview avant de poster un commentaire? Mais que fait le maître des lieux!
[Reply]
[…] twitter rss Sens et enjeux des modèles de stockage et d’accès aux données […]
[…] Sens et enjeux des modèles de stockage et d’accès aux données […]
[…] architecture logicielle avec lesquelles il faut composer. Cette note fait écho à celle sur le sens et les enjeux des modèles de stockage et d’accès aux données, et elle me permettra de faire la transition vers la question de l’affordance dans les […]
[…] y a une dualité [mot qui a un sens précis en mathématique dans la théorie des catégories, cf. Sens et enjeux des modèles de stockage et d’accès aux données] entre un système de log et une table de base de données : la table reflète la valeur actuelle […]
Christian Reply:
avril 20th, 2011 at 5:55
@ Pierre D : non je ne vois pas de XRX, en fait cela se fait plutôt à la sauce SBA : http://www.christian-faure.net/2009/08/01/search-based-applications/
[Reply]