~/sebl[og]

Alors que je jouais avec PostgreSQL 9.0, j'ai cherché à obtenir le comportement de l’agrégat string_agg ( second argument pour définir le séparateur ), mais dans les versions 8.3 et 8.4

En ce jour de sortie d'un objet médiatique de consommation, je vais tenter une analogie foireuse :

« Si Apple fait du Playmobil, alors GNU/Linux fait du Lego. Et j'ai toujours préferé les Lego Technic ... »

En fait, ce qui est important, à mon avis, c'est la bidouillabilité, c'est à dire le fait de s'approprier l'objet, et de pouvoir l'utiliser comme on le souhaite.

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.

Yahoo vient d'annoncer qu'ils utilisent PostgreSQL pour stocker 2 pétaoctets de données¹. Ce qui en ferait la plus grosse base de données au monde.

Certes, ils utilisent une version modifiée de PostgreSQL, ils ont retirés le support des transactions, et utilisent un stockage en mode colonne, à la place du traditionnel stockage en mode ligne. De plus, l'éxécuteur de requètes permet d'utiliser plusieurs coeurs de processeur. Mais tout de même, c'est la license et la qualité du code de PostgreSQL qui font qu'il a été choisi.

Il est intérressant d'apprendre que Yahoo va supporter et aider le projet.

Ceci n'aurait pas été possible avec une base de données propriétaire, et montre bien la superiorité du logiciel libre, au code ouvert, sur le logiciel propriétaire.

¹ : Un pétaoctet, c'est mille téraoctets, un million de gigaoctets, un milliard de mégaoctets. Un mégaoctet, c'est un million de caractères, c'est 1 minute de musique au format Ogg-Vorbis, c'est une photo numérique de 4 mégapixels.

PostgreSQL 8.3 est donc sorti lundi dernier, et d'après les premiers tests que j'ai pu faire, cette nouvelle version est vraiment intéressante.

Quelques liens sur le sujet :

• http://www.postgresqlfr.org/?q=node/1547
• http://linuxfr.org/2008/02/06/23663.html
• http://people.planetpostgresql.org/gsmet/index.php?/archives/1-A-day-with-8.3.0-on-cityvox.fr.html
• http://docs.postgresqlfr.org/current/

Une seconde édition de mon livre sur PostgreSQL est paru, intégrant les nouveautés de la version 8.2 de PostgreSQL.

Il est toujours disponible aux éditions ENI. Tous les renseignements sur trouvent sur la page qui lui est dédiée.

A noter que la version 8.3 de PostgreSQL est en préparation. Actuellement, la version 8.3 est dans la phase « béta », et est donc disponible pour des tests.

C'était en cours depuis plusieurs mois, et c'est officiel depuis cette semaine, je commence donc l'écriture d'un livre sur Postgresql 8. Il sera édité aux Editions ENI, qui édite des ouvrages informatiques.

Il n'existe pas, en langue française, d'ouvrage à jour sur Postgresql, les seuls qui existent ne couvrent pas la dernière version du logiciel, la 8, et ne sont pas orienté 'Administration'.

Il fallait donc combler un manque, et ce sera chose faite dans quelques mois.

J'animerais la semaine prochaine une formation sur PostgreSQL, chez Anaska : http://www.postgresql.org/about/event.329.

et, la citation de la semaine, de Bruce Momjan :

It was cheaper to pay to add missing features to PostgreSQL than to buy Oracle.

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 :-)

• Setting the scope for light-weight Web-based applications
• Nokia Semantic Web Server
• The Sphere of Design
• Forum Alsacréations : CSS et Standards Web
• Geckozone : Forum