Je ne suis pas fan des procédures stockées
Les procédures stockées sont PLUS maintenables car: * Vous n'avez pas à 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 si vous souhaitez renvoyer une colonne supplémentaire, ou autre chose. Le nombre de fois où vous pouvez changer le SQL de manière «transparente» sous votre application est assez petit dans l'ensemble
- Vous finissez par réutiliser du code SQL.
Les langages de programmation, C # inclus, ont cette chose étonnante, appelée fonction. Cela signifie que vous pouvez invoquer le même bloc de code à partir de plusieurs endroits! Incroyable! Vous pouvez ensuite mettre le code SQL réutilisable à l'intérieur de l'un d'eux, ou si vous voulez obtenir une technologie très avancée, 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 documents 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, vous avez réalisé qu'il y a un petit problème avec le code SQl alors préférez-vous ...... changez le proc à 1 endroit ou poussez le code à tous les serveurs Web, réinstallez toutes les applications de bureau (clickonce pourrait aider) sur toutes les fenêtres
Pourquoi vos applications Windows se connectent-elles directement à une base de données centrale? Cela semble être un énorme trou 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, il 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 aux serveurs Web ce mois-ci et 1 à la base de données, vous perdez à peine beaucoup si vous transférez 21 éléments aux serveurs Web et zéro à la base de données.
Revue de code plus facile.
Pouvez-vous expliquer comment? Je ne comprends pas. En particulier, car les sprocs ne sont probablement pas sous contrôle de source et ne sont donc pas accessibles via les navigateurs SCM basés sur le Web, etc.
Plus contre:
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 en contrôle de source deviennent un cauchemar.
Il y a aussi la question du simple effort. Il pourrait être judicieux de tout décomposer en un million de niveaux si vous essayez de justifier à votre PDG pourquoi il leur a juste coûté 7 millions de dollars pour créer des forums, mais sinon, créer unproc stocké pour chaque petite chose est juste un travail d'âne supplémentaire sans avantage.