Et tu dois tout réécrire quand tu change. Ça revient à avoir autant d'importance que le langage dans lequel tu code.
Quand tu changes quoi ?
Les procédures stockées définissent une interface public, tu peux changer le code des procs de facon transparente.
On part du principe que :
- les procédures stockées gèrent la logique métier.
- le client dans un langage X gère l'affichage.
Tu peux changer de client facilement, passer d'un client lourd à un client léger sans perdre toutes les règles métier.
Tu évites de positionner des triggers à la con, parce qu'un insert est éparpillé dans 50 points du programme, …
Il est beaucoup plus simple d'écrire du code correcte avec des procédures stockées, par exemple lors de l'utilisation de bind variable.
Ensuite ca peut éviter d'avoir des développeurs qui n'ont pas la logique SQL mais uniquement itérative de faire des boucles à tout va pour manipuler des données, ce qui peut être très pénalisant en terme de performance.
Si tu dois changer de SGBD il me semble que la signature des procédures stockées et plus portable.
Par contre pour porter le code c'est un autre histoire, il existe des outils mais je ne sais pas ce qu'ils valent.
De plus changer de SGBD peut être très problématique :
- façon de gérer les transactions par défaut (DB2, Sysbase IQ ne font pas de "read committed" et ce n'est pas simple à mettre en oeuvre avec MS Sql Server).
- différence subtile dans la fonctionnement des contraintes uniques (différent entre Oracle et MS Sql Server par exemple. D'un point de vue de la norme ils ont tous les 2 raisons)
- Les bons usages liés à un SGBD particulier.
Les requêtes vraiment portables sont forcément simple tu dois te limiter à la norme minimum du sql et oublier par exemple les requêtes analytiques.
[^] # Re: Mélange de langage
Posté par Kangs . En réponse au journal Témoignage d'expérience de nosql avec PHP et Mongodb. Évalué à 4.
Quand tu changes quoi ?
Les procédures stockées définissent une interface public, tu peux changer le code des procs de facon transparente.
On part du principe que :
- les procédures stockées gèrent la logique métier.
- le client dans un langage X gère l'affichage.
Tu peux changer de client facilement, passer d'un client lourd à un client léger sans perdre toutes les règles métier.
Tu évites de positionner des triggers à la con, parce qu'un insert est éparpillé dans 50 points du programme, …
Il est beaucoup plus simple d'écrire du code correcte avec des procédures stockées, par exemple lors de l'utilisation de bind variable.
Ensuite ca peut éviter d'avoir des développeurs qui n'ont pas la logique SQL mais uniquement itérative de faire des boucles à tout va pour manipuler des données, ce qui peut être très pénalisant en terme de performance.
Si tu dois changer de SGBD il me semble que la signature des procédures stockées et plus portable.
Par contre pour porter le code c'est un autre histoire, il existe des outils mais je ne sais pas ce qu'ils valent.
De plus changer de SGBD peut être très problématique :
- façon de gérer les transactions par défaut (DB2, Sysbase IQ ne font pas de "read committed" et ce n'est pas simple à mettre en oeuvre avec MS Sql Server).
- différence subtile dans la fonctionnement des contraintes uniques (différent entre Oracle et MS Sql Server par exemple. D'un point de vue de la norme ils ont tous les 2 raisons)
- Les bons usages liés à un SGBD particulier.
Les requêtes vraiment portables sont forcément simple tu dois te limiter à la norme minimum du sql et oublier par exemple les requêtes analytiques.