Je ne suis pas fan des procédures stockées
Les procédures stockées sont PLUS maintenables car :* Vous n'avez pas besoin de recompiler votre application C# chaque fois que vous souhaitez modifier du SQL
Vous finirez par le recompiler de toute façon lorsque les types de données changent, ou que vous souhaitez renvoyer une colonne supplémentaire, ou quoi que ce soit. Le nombre de fois où vous pouvez modifier de manière "transparente" le SQL sous votre application est assez faible dans l'ensemble
- Vous finissez par réutiliser le code SQL.
Les langages de programmation, C# inclus, ont cette chose étonnante, appelée une fonction. Cela signifie que vous pouvez invoquer le même bloc de code à partir de plusieurs endroits ! Étonnante! Vous pouvez ensuite mettre le code SQL réutilisable à l'intérieur de l'un d'entre eux, ou si vous voulez être vraiment high-tech, vous pouvez utiliser une bibliothèque qui le fait pour vous. Je crois qu'ils s'appellent Object Relational Mappers, et sont assez courants de nos jours.
La répétition de code est la pire chose que vous puissiez faire lorsque vous essayez de créer une application maintenable !
D'accord, c'est pourquoi les procs stockés sont une mauvaise chose. Il est beaucoup plus facile de refactoriser et de décomposer (diviser en parties plus petites) le code en fonctions que SQL en... blocs de SQL ?
Vous avez 4 serveurs Web et un tas d'applications Windows qui utilisent le même code SQL Maintenant que vous avez réalisé qu'il y a un petit problème avec le code SQl alors préférez-vous ...... changer le proc en 1 endroit ou pousser le code à tous les serveurs Web, réinstallez toutes les applications de bureau (clickonce pourrait aider) sur toutes les fenêtres fenêtres
Pourquoi vos applications Windows se connectent-elles directement à une base de données centrale ? Cela semble être une énorme faille de sécurité et un goulot d'étranglement car il exclut la mise en cache côté serveur. Ne devraient-ils pas se connecter via un service Web ou similaire à vos serveurs Web ?
Alors, poussez 1 nouveau sproc, ou 4 nouveaux serveurs Web ?
Dans ce cas, c'est c'est plus facile de pousser un nouveau sproc, mais d'après mon expérience, 95% des "changements poussés" affectent le code et non la base de données. Si vous transférez 20 éléments vers les serveurs Web ce mois-là et 1 vers la base de données, vous ne perdez pas grand-chose si vous transférez plutôt 21 éléments vers les serveurs Web et zéro vers la base de données.
Réviser plus facilement le code.
Pouvez-vous expliquer comment ? Je ne comprends pas. D'autant plus que les sprocs ne sont probablement pas dans le contrôle de code source et ne sont donc pas accessibles via les navigateurs SCM basés sur le Web, etc.
Plus d'inconvénients :
Les Storedprocs vivent dans la base de données, qui apparaît au monde extérieur comme une boîte noire. Des choses simples comme vouloir les mettre dans le contrôle de code source deviennent un cauchemar.
Il y a aussi la question de l'effort pur. Il peut être logique de tout décomposer en un million de niveaux si vous essayez de justifier auprès de votre PDG pourquoi cela leur a coûté 7 millions de dollars pour créer des forums, mais sinon, créer un proc stocké pour chaque petite chose n'est qu'un travail d'âne supplémentaire pour non avantage.
