De l’arrivée des ORMs

En passant

projet pour la fontaine de l’éléphant de la Bastille, Aquarelle de Jean-Antoine Alavoine (1776-1834)

Un des changements récents et inévitable de notre nouvelle ère numérique est l’objectivation  des bases de données, et l’introduction des ORMs. Je me frotte a ces beautés fatales depuis plusieurs années et si les débuts furent assez séduisants mais houleux, j’en conclus avec le recul que l’évolution est incontournable.
Essentiellement de part la proéminence des langages objects : même si C tient le haut du pavé sur Tiobe, C++ C# et java sont juste derrière (voir devant depuis janvier). Quoi de plus naturel que de persister directement les objets en bases, sans mapping manuel qui est source d’erreurs.

Seulement, ces outils puissants sont aussi complexes et ne remplacent pas une connaissance minimale de SQL, faute de se tirer une balle dans le pied. Si vous ne regardez pas les requetes générées ou le modèle, attention aux surprises lors de la mise en production. Sur de gros volume de données, cela pardonne moins facilement.

Vous serez donc bien aise de lire les mauvaises pratiques d’hibernate et d’autres avant de vous lancer plus en avant, et de trouver un bon tutoriel (ici pour nhibernate).

A contrario, il existe de nombreux cas où l’utilisation d’un ORM est trop coûteux, et vos premiers projets avec cette technologie seront bien sur plus lents.

Je vois plusieurs effets directs de cette arrivée à maturité des ORM :

  • un premier est que les développeurs s’intéressent plus à ce qui se passe coté base de donnée et vont moins faire de copier/coller, sans doute parce que l’ORM les soulage des tâches les moins nobles
  • un autre est que les couches d’accès aux données peuvent se simplifier considérablement,
    il est possible de les faire tenir en une centaine de ligne nonobstant les entités.
  • un dernier est le blowback, l’arrivée des noSQL, non pas pour stocker des grosses quantités de données, mais pour s’astreindre des difficultés de la modélisation (et je rejoins l’avis de monty).

Un cas classique est le stockage d’objets sérialisés (en json, ou en xml) sur des bases jeunes (mongoDB) ou des graphes d’objets dans des blobs… avec les médiocres performances ou la perte de fonctionnalités: plus de critères, plus de compatilité ascendante.

Les développeurs ne savent-ils plus modéliser, ou le DBA n’a-t-il plus de rôle  ? C’est un éventualitée mais dans ce cas c’est effectivement la fin de vie des SGBDR car ils ne sont performants qu’avec des modèles bien fait.

La prochaine étape sera peut-être alors le retour en grâce des bases de données objets qui existent depuis nombreuses années mais n’ont pas réussit à s’imposer face aux SGBDR traditionnels, même s’ils sont plus performants sur les opérations de CRUD.
A moins que les SGBDR n’intègrent de plus en plus l’objet… A cet égard, l’exemple CRUD de mysqlcluster est impressionant.

Ou alors des SGBDR qui crée

Une anecdote pour finir: savez-vous que Posgresql gère l’héritage de table depuis la version 7 ?

Publicités