Procédures stockées - Fin des jours

Question

J'écoute le podcast Hanselminutes : " StackOverflow utilise ASP.NET MVC - Jeff Atwood et son équipe technique ". Au cours du podcast, ils parlent du serveur SQL et disent quelque chose du genre "Les jours de la procédure stockée sont terminés".

Je ne suis pas un DBA mais cela m'a pris un peu par surprise. J'ai toujours supposé que les SP étaient la voie à suivre pour la rapidité (puisqu'ils sont respectés) et la sécurité, sans parler de l'évolutivité et de la maintenabilité. Si ce n'est pas le cas et que les SP sont à bout de souffle, qu'est-ce qui les remplacera ou que devrions-nous faire à l'avenir ?

Answer 1

Je suis peut-être trop vieux jeu, ou trop paresseux, ou les deux, mais je ne suis pas d'accord. A maintes reprises, les procédures stockées ont "sauvé la mise" car lorsqu'un changement ou un bug mineur du back-end apparaît nous devons seulement corriger la procédure stockée au lieu de mettre à jour l'application de bureau sur plusieurs dizaines de postes de travail plus le serveur web. En outre, les utilisateurs ne sont pas interrompus. Cela évite beaucoup d'efforts et de tracas aux utilisateurs.

En outre, certaines opérations de base de données seront plus efficaces sur le serveur plutôt que de faire des allers-retours sur le réseau, notamment lorsqu'une procédure stockée en appelle une autre qui en appelle une autre, etc.

EDIT : dans une architecture SOA, le problème de la mise à jour des applications clientes est atténué (merci maud-dib), mais les procédures stockées qui s'appellent les unes les autres sont toujours plus efficaces que les multiples allers-retours du réseau vers la couche SOA. Et la mise à jour de la couche SOA n'est pas toujours triviale non plus.

Answer 2

Sur les systèmes modernes, les requêtes paramétrées sont compilées et mises en cache sur le serveur, de sorte qu'elles sont tout aussi rapides qu'une procédure stockée. Elles présentent également la plupart des mêmes caractéristiques de sécurité.

Pour les bases de données qui servent une seule application, il est plus logique de disposer de la logique de requête à l'endroit approprié du code. Cela permet notamment de faciliter le contrôle de la source. Si vous conservez les procédures stockées sur le serveur, en assurer le suivi peut rapidement devenir un véritable casse-tête. De plus, si vous utilisez un outil ORM, il se peut que vous n'ayez pas beaucoup de SQL réel de toute façon.

Si votre base de données sert plusieurs applications différentes, vous pouvez toujours utiliser des procédures stockées pour faire respecter les règles de gestion entre les applications.

Answer 3

Je dirais que les PS ne sont pas maintenables et qu'ils ne sont pas évolutifs. Demandez à n'importe quel développeur qui a dû ajouter des fonctionnalités à un système lourd de PS. Pourquoi avoir la moitié de votre logique dans une couche différente ? Il n'y a rien à remplacer, il suffit de ne pas les utiliser.

J'ai cherché cet article sur Google.

Answer 4

Les SPs sont probablement la voie à suivre si vous êtes SEULEMENT concerné par la vitesse. Mais si vous vous souciez de l'évolutivité ou de la maintenabilité, les SP ne sont peut-être pas les meilleurs. Notre architecture est construite sur des SPs et après 10 ans de code, elle est très difficile à maintenir et très boguée. Un bon mappeur ORM pourrait être un meilleur choix.

Answer 5

Je continue d'entendre l'argument selon lequel les PS sont bons si vous avez plusieurs applications qui se connectent à la base de données ou que cela facilite la correction des bogues.

C'EST À CELA QUE SERT UNE COUCHE DE SERVICE !

La logique métier se trouve dans la couche service, la logique applicative dans l'application/le site web.

Il est beaucoup plus difficile de déboguer et de maintenir des centaines de SP (surtout s'ils sont générés) que de maintenir un code bien écrit qui communique avec une base de données via un outil ORM.