~/sebl[og]

Je suis administrateur de bases de données, c'est mon métier. L'outil principal avec lequel je travaille est PostgreSQL, qui est un système de gestion de bases de données relationnelles, un des meilleurs outils qui soit.

La prise en main pour un développeur de logiciel de ce type d'outil est loin d'être évidente. La plupart du temps, ce qui importe pour un développeur est la façon dont son code fonctionne, et dont l'architecture du programme est mise en place. Il est rarement intéressé par la façon dont sont stockées les données qu'il manipule, et si le sujet l'intéresse, il le voit au travers de son modèle de données, qui, la plupart du temps, est un modèle objet.

On voit donc régulièrement s'opposer deux façons de penser : les modèles relationnels et les modèles objets ; Une des pire chose qui puisse arriver est de coller un ORM entre les deux modèles : on obtient rarement un compromis acceptable, d'un coté comme de l'autre. Au mieux, l'ORM va permettre de prendre en main progressivement la base de données relationnelle afin de faire correspondre le code avec la base. Ici, il est important de noter que je suis DBA, de mon point de vue, c'est au code de coller au modèle relationnel.

Malheureusement, les contraintes de développement en entreprise étant ce qu'elles sont, les modèles relationnels des bases de données ne sont pas toujours conçues par des concepteurs versés dans l'art des ensembles. On retrouve donc régulièrement des modèles qui consistent simplement à sérialiser des objets et à les associer à des clés. Ce qui revient à stocker des paires clés/valeurs. Et pour cela, nul besoin d'un SGBDR.

De plus, des bases de données relationnelles comme PostgreSQL sont de très bons outils transactionnels, mais ils existent des outils qui peuvent être plus pratique lorsqu'on ne fait que des lectures de données et très peu d'écriture.

Or, on passe plus de temps à lire des tweets ou des profils Facebook qu'a y raconter sa vie ( quoique ), et ces outils manipulent des données qui sont très faiblement modélisés.

Depuis quelques années, de très gros sites Webs ( Amazon, Google, Facebook, ... ) ont donc amorcé une réflexion sur leurs besoins en base de données, et y répondent aujourd'hui par la publication de documents et d'outils qui font parti de la mouvance NoSQL. Récemment, c'est Twitter qui annoncait se passer de MySQL pour se diriger vers une base de données très différentes : Cassandra.

On voit ici que s'oppose deux modèles : des bases de données très structurés, et ayant essentiellement des besoins en écritures ( par exemple, une application comptable ), et des bases de données non-structurées, accédées essentiellement en lecture.

Je vais donc tenter de comprendre, d'expliquer et de prendre en main la seconde famille d'outils, que je ne connais pas, dans une séries d'articles sur ce blog.

L'edition de contenu sur le web dépend d'outils de publication. L'outil de base, ou plutot, les outils de base sont les standards utilisés pour mettre à disposition ces contenus : les schémas html et xhtml, les feuilles de styles CSS, les formats d'images Png, jpeg et gif.

En partant du principe que ces standards sont librement disponibles et édités par les acteurs du marché, je ne vois pas de bonnes raisons de ne pas les utiliser. Alors pourquoi est-ce que certains persistent à ne pas delivrer de contenus respectant ces standards ? Y-a-t-il une bonne raison à cela ?

Imagine-t-on fourni un document Docbook ne respectant pas le schéma ? non ! Imagine-t-on créer une feuille Xslt non-conforme aux schémas ? non, bien-sur. Alors pourquoi continue-t-on a faire des documents html non-conforme ?

Aujourd'hui, les navigateurs Web, les outils qui nous permettent de lire les documents Html, ont deux façons de lire les données qu'on leur donne : un mode de respect stricts des standards, et un autre, le quirks-mode, qui permets de faire un peu n'importe quoi avec nos balises html. Quand est-ce que ce mode Quirks deviendra obsolete ? Quand IE7 sortira, avec un support complet des standards ? peut-être :-)

A lire, un excellent article de Karl Dubost sur la maltraitance du Html 4.01 par les développeurs : HTML 4.01, une star bien mal comprise.

Dans la même veine, le billet de Fred Cavazza : XHTML, web sémantique et gestion de contenu.

Un de mes projets professionnels en cours est la réalisation d'un CMS utilisable et accessible.

Jeffrey Veen fait le constat que les outils Open-Source actuels ne sont pas simple à utiliser, à prendre en main : http://www.veen.com/jeff/archives/000622.html". Je ne peux qu'être d'accord avec lui, car le fait que je sois en train de développer mon propre outil est la conséquence des défauts des CMS Open-source existants, que ce soit Spip, Mambo, Lodel, ou d'autres. They sucks really badly.

Donc, bien-sûr, je devrais faire attention à ne pas tomber dans ces travers, et réaliser un outil complet, en essayant de respecter les différents points qu'il suggère. Je peux aussi m'appuyer sur le mémoire de Philippe Lahaye, qui est une mine d'or en la matière.

Un bon exemple, dans un domaine connexe, est celui de DotClear, un outil de blog, celui avec lequel j'écris ce billet. Il s'installe très facilement et fonctionne bien. De plus il respecte les standards du Web, ce qui est un point essentiel.

[Update, 05-10-2004] Un critère important, qui ne concerne pas les points précédents, est la portabilité des bases de données. En effet, je travaille essentiellement avec Postgresql, qui est un excellent SGBD. Malheureusement, les hébergeurs le proposant sont trop rares, et donc, l'utilisation de Mysql est nécessaire pour rendre l'outil 'utilisable'.

La syndication de contenu est le fait de mettre � diposition sur un site Web une page au format XML. Or, un fichier XML n'est rien si il n'est pas accompagné d'un schéma, décrivant la façon dont est construit le fichier.

Dans le cas qui nous interresse, ce n'est pas évident d'avoir une synthèse claire sur le sujet. Je vais être bref, en essayant de ne rien oublier.

Le format RSS a été crée par Netscape en 1999, et repris par la societe UserLand en 2000. Il a évolué sous les version 0.90, 0.91 et 0.92. Il s'agit en fait d'une Dtd qui décrit comment doit être écrit un fichier XML.

Un groupe de travail a ensuite proposé au W3C le format RSS 1.0 (2000), qui cassait complètement la compatibilité avec les formats précedents. Ce format est basé sur RDF, qui est un ensemble de recommandations visant � créer un Web Sémantique.

Le format RSS 2.0 (2003) est une évolution de RSS 0.92, par le même personnage qui a travaillé sur RSS chez UserLand.

Le format Atom a été crée dans le but de simplifier les différents formats existants. Il repose sur le même principe que les formats RSS, c'est-� -dire un fichier XML, avec un schéma connu. Ce format fait l'objet d'un groupe de travail au sein de l'IETF.

Donc, maintenant, on se retrouve avec 3 formats concurrents (j'exclus volontairement les formats 0.9x) , RSS 1.0, RSS 2.0 et Atom, respectivement soutenus par le W3C, l'université de Harvard, et l'IETF. Le choix n'est donc pas évident lorsqu'on est développeur, et qu'on doit choisir un format.

Un premier élément de réponse peut venir du fait qu'un fichier XML ne suffit pas pour avoir un format ouvert, encore faut-il que la description le soit aussi. Et pour qu'un format devienne un standard, il faut qu'il soit élevé � ce rang par une entité crédible. Or, qui est crédible pour publier des standards du Web, sinon le W3C ?