Rare ?
Au contraire, c'est super répandu !
J'irais même plus loin: c'est quoi l'intérêt de développer un Système d'Information incapable de tenir la charge ?
Là où je suis d'accord, c'est qu'un ORM dans ce cas, c'est pas la joie. Typiquement:
- ça créé une transaction (par ce qu'on en a besoin pour assurer l'intégrité des données)
- ça fait plein de petites requêtes qui, cumulées, utilisent pas mal de ressources
- pendant tout le temps où la transaction est restée ouverte, d'autres applications ont eu le temps de faire des timeouts...
À ce niveau là, je préfère une bonne procédure stockée qui fait des bons gros traitements par lots, et de manière efficace.
C'est vrai que la POO c'est rassurant parce qu'on comprend les interactions entre objets, et que l'algèbre relationnelle ça fait peur à pas mal de gens. C'est vrai que certaines procédures stockées font mal à la tête quand on doit les relire (surtout si elles sont mal indentées, c'est une horreur !) mais souvent, quand on voit tout ce qu'il faut écrire en POO pour arriver au même résultat (mais en moins performant), c'est même pas la peine !
Un autre avantage des procédures stockées, c'est que si on se rend compte d'un problème, on a juste à modifier la procédure pour que les changements prennent immédiatement effet, pas besoin de tout recompiler et redéployer...
J'ai un collègue développeur qui m'a raconté qu'il ne s'était jamais intéressé au SQL... jusqu'à ce qu'il me rencontre et qu'il voie ce qu'il est possible de faire avec du SQL. Depuis il me pose plein de questions.
À la base, je ne suis pas partisan d'une solution plutôt qu'une autre. Mais quand on a des deadlines parfois assez serrées, on va vers la solution qui permet de réduire les temps de développement. Et quand à cela s'ajoutent des contraintes de performance...
Partager