-
Il y a différents intérêts de faire des procédures stockées.
D'une manière générale, avoir le code SQL sur le serveur SQL est aussi logique de stocker le "code PHP" sur le serveur WEB.
L'éparpillement de différents code en différents sites est plutôt une plaie lorsqu'on se lance dans une mise à jour, à cause de la gestion du périmètre.
Personnellement, je milite pour concevoir les accès aux bases de données comme le développement d'une API : une bibliothèque d'objets exposés dont leur mode de consommation est le plus "standard" possible. Le code interne est la compétence des développeurs de base de données.
Les procédures et les vues sont les moyens opérationnels d'arriver à faire ça.
Lorsqu'on fait son projet on pense que la base est un élément interne et dévolu au projet.
Ainsi associée, la base devient un mal nécessaire au développement.
Avec le temps, on constatera que ce n'est pas tenable, que les données sont des ressources d'entreprise et pas d'un projet.
Concevoir la base comme une ressource, ou plutôt comme une source, donne au projet la dimension qu'il mérite en l'asseyant sur des besoins multiples.
-
Merci pour ce point de vue très intéressant, je vais creuser cette notion de API
