Re: [TECH] Re: Re: Base de données objet libre

[Sébastien Dinot <sdinot AT april.org>]

Bonjour à tous,

Je ne suis un spécialiste ni des bases de données objet, ni des ORM
(j'ai juste eu recours à ce tels outils une fois ou deux) mais les
arguments de François méritent à mon sens quelques commentaires.

francois AT dechelle.net a écrit :
| Enfin, en ce qui concerne les ORM (Object Relational Mapping),
| effectivement ça peut répondre aux besoins, mais il y a plusieurs
| inconvénients:
| - gestion de l'intégrité relationnelle est à faire au niveau du code
|   applicatif

J'approuve pleinement cet argument mais il faut préciser en quoi il
est important :

Assurer l'intégrité référentielle des données, c'est le travail de
tout SGBD digne de ce nom (SQLite - que j'apprécie beaucoup par
ailleurs - ne le fait pas mais cette bibliothèque n'a jamais eu la
prétention d'être un véritable SGBD).

- Les fonctionnalités qui s'y rapportent font l'objet d'une attention
  particulière. Par exemple, PostgreSQL a souffert dans sa jeunesse de
  sévères critiques à cet égard. Du coup, les développeurs ont
  redressé la barre et il est irréprochable [à ce niveau] depuis bien
  des années.

- Le code des SGBD est sérieusement optimisé et la synchronisation des
  données liées à une donnée détruite ou mise à jour ne nécessite ni
  requête SQL, ni dialogue supplémentaires entre le SGBD et
  l'application. Du coup, on a tout intérêt à laisser la charge de
  l'intégrité référentielle au SGBD. Le gain de performance est réel.

| - solutions mono-langage (p.e. hibernate == Java)

Là, par contre, je ne vois pas en quoi cet argument est spécifique aux
ORM. Quelque soit le langage de développement utilisé, la migration
d'un projet vers un autre langage nécessite la réécriture du code,
notamment des structures ou objets de stockage des données en mémoire
et de la couche d'accès aux données stockées en base. Pour ce qui est
des données existantes, un ORM produit en base des tables SQL
standard, peu ou prou indépendantes de l'ORM qui les a produites (le
seul risque que j'entrevois à ce niveau concerne les clés primaires
générées automatiquement par l'ORM et dont la logique de nommage peut
varier d'un ORM à l'autre).

D'un autre côté, si on opte pour un SGBD objet et que pour des raisons
de performances, on désire plus tard redévelopper l'application en C
(ou autre langage non objet), on se heurte à un sérieux problème de
migration.

Quant à se passer d'ORM et de base de données objet, c' est
certainement la solution la plus portable mais c'est aussi se résigner
à produire plus de code (et plus de bogues).

Je crois donc qu'une fois de plus, il n'y a pas de solution
universelle. Lorsqu'on met en oeuvre un outil tel que Ruby On Rails,
on a tout intérêt à adopter l'approche ORM (je ne suis d'ailleurs pas
certain que l'on puisse faire sans puisque, si j'ai bien compris,
l'ActiveRecord est l'un des piliers de ROR). Les SGBD objet ont une
élégance alléchante mais, sachant qu'il n'existe pas beaucoup
d'alternatives libres, quel risque cela fait-il peser sur le projet en
cas de manque de performance du SGBD objet ? Le MCD est alors à revoir
de fond en comble ainsi que la couche d'accès aux données.

A++, Sébastien

-- 
Sébastien Dinot, sdinot AT april.org
Secrétaire de l'APRIL (http://www.april.org)
Association pour la Promotion et la Recherche en Informatique Libre