Je suis d'accord avec la métaphore mais, dans ce débat, nous sommes il y a tension entre (au moins) deux aspects complètement différents:
- Des traitements plus près des données que permettent les Stored Procedures ont des atouts côté performances indiscutable (lié à la vitesse finie de la lumière)
- Un ORM permet de faire vite et pas cher (en se passant de DBA), c'est indéniable.
Problèmes:
- Faire des choses compliquées sans DBA,
- Compliquer les choses et exploser les coûts,
- Faire vite une application promise à croître. A terme elle deviendra instable et remettre d'équerre un machin tordu sans valeur ajoutée fonctionnelle sera un exercice incertain et risqué: tant qu'on pourra ajouter du hard, des caches,... çà pourra le faire... jusqu'au moment ou on se résignera à tout jeter à la poubelle.
Solution à vite, pas cher, évolutif???
En ce moment, j'explore les possibilités d'ORM de type Active Records Pattern.
J'ai toujours un ORM mais les instances sont des lignes de tables: on limite un peu l'expressivité côté ORM. Mais la base de données ne se limite pas à un concept de persistance...
Elle reste fortement matérialisée et cela permet d'y enfouir des SP dans un deuxième temps.
- W
Partager