ORM non conseillé pour les applications "lecture seule"
J'ai récemment discuté avec un collègue de la grille de décision simplifiée qui était proposée à des projets de développement (dans le cadre d'une cellule archi) dans leur choix de techno d'accès base :
- pour des applications accédant à la base en lecture/écriture, l'ORM est conseillé
- pour des applications accédent en lecture seule, l'ORM est déconseillé, utilisez plutôt SQL avec un requêteur "classique"
J'avais au premier abord un problème avec cette deuxième recommandation. Lire la base en travers via jointure est désormais quasi aussi "productif" et performant en langage ORM qu'en SQL. Et lire la base en suivant les relations interentités est, pour le coup, une opération carrément transparente pour l'ORM, il n'y a quasiment rien à exprimer !
Mais mon collègue me fait remarquer qu'en SQL non plus, ça peut aller très vite... Pour lire la base en suivant les relations, un bon vieux DataSet mappé sur Table et gestion du Master/Detail (bref de la foreign key) est tout aussi "productif", par exemple (le Dataset de MS est très fort sur ce plan par ex)...
Après réflexion, oui, l'abstraction objet n'est pas très utile dans ce cas (peut être le polymorphisme, mais c'est un besoin tellement ponctuel); SQL est vraiment le bon langage à utiliser directement !
Après réflexion, passer du temps à coder le mapping entre des objets et des tables n'est vraiment rentable que si
1) on veut faire générer le SQL de lecture mais aussi d'écriture, 1 mapping vaut s'il remplace au moins 2 SQL
2) si on souhaite coder des règles de gestion autour de ces objets; or dans le contexte d'une "application accédant en lecture seule", il y a peu de chance qu'on ait de telle "logique" à implémenter autour des objets; ou bien dans des cas très spécifiques, où il s'agirait de coder des algorithmes métiers pour parcourir les relations par ex...
Certes, la recommandation reste insatisfaisante, elle semble un peu "maladroite". Mais en creusant, on trouve de très intéressantes justifications.
- pour des applications accédant à la base en lecture/écriture, l'ORM est conseillé
- pour des applications accédent en lecture seule, l'ORM est déconseillé, utilisez plutôt SQL avec un requêteur "classique"
J'avais au premier abord un problème avec cette deuxième recommandation. Lire la base en travers via jointure est désormais quasi aussi "productif" et performant en langage ORM qu'en SQL. Et lire la base en suivant les relations interentités est, pour le coup, une opération carrément transparente pour l'ORM, il n'y a quasiment rien à exprimer !
Mais mon collègue me fait remarquer qu'en SQL non plus, ça peut aller très vite... Pour lire la base en suivant les relations, un bon vieux DataSet mappé sur Table et gestion du Master/Detail (bref de la foreign key) est tout aussi "productif", par exemple (le Dataset de MS est très fort sur ce plan par ex)...
Après réflexion, oui, l'abstraction objet n'est pas très utile dans ce cas (peut être le polymorphisme, mais c'est un besoin tellement ponctuel); SQL est vraiment le bon langage à utiliser directement !
Après réflexion, passer du temps à coder le mapping entre des objets et des tables n'est vraiment rentable que si
1) on veut faire générer le SQL de lecture mais aussi d'écriture, 1 mapping vaut s'il remplace au moins 2 SQL
2) si on souhaite coder des règles de gestion autour de ces objets; or dans le contexte d'une "application accédant en lecture seule", il y a peu de chance qu'on ait de telle "logique" à implémenter autour des objets; ou bien dans des cas très spécifiques, où il s'agirait de coder des algorithmes métiers pour parcourir les relations par ex...
Certes, la recommandation reste insatisfaisante, elle semble un peu "maladroite". Mais en creusant, on trouve de très intéressantes justifications.
Commentaires