Quels sont les avantages et les inconvénients de conserver SQL dans les processus stockés par rapport au code [fermé]

Quels sont les avantages / inconvénients de conserver SQL dans votre code source C # ou dans les processus stockés? J'en ai discuté avec un ami sur un projet open source sur lequel nous travaillons (Forum C # ASP.NET). À l'heure actuelle, la plupart de l'accès à la base de données se fait en créant le SQL inline en C # et en appelant à la base de données SQL Server. J'essaie donc de déterminer laquelle, pour ce projet particulier, serait la meilleure.

Jusqu'à présent, j'ai:

Avantages pour dans Code:

• Plus facile à entretenir - pas besoin d'exécuter un script SQL pour mettre à jour les requêtes
• Port plus facile vers une autre base de données - aucun processus à porter

Avantages pour les processus stockés:

• Performance
• Sécurité

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.

Ceci est en cours de discussion sur quelques autres threads ici actuellement. Je suis un partisan cohérent des procédures stockées, bien que de bons arguments pour Linq à Sql soient présentés.

L'incorporation de requêtes dans votre code vous relie étroitement à votre modèle de données. Les procédures stockées sont une bonne forme de programmation contractuelle, ce qui signifie qu'un DBA a la liberté de modifier le modèle de données et le code dans la procédure, tant que le contrat représenté par les entrées et sorties de la procédure stockée est maintenu.

Le réglage des bases de données de production peut être extrêmement difficile lorsque les requêtes sont enfouies dans le code et non dans un emplacement central facile à gérer.

[Modifier] Voici une autre discussion en cours

À mon avis, vous ne pouvez pas voter pour oui ou non sur cette question. Cela dépend totalement de la conception de votre application.

Je vote totalement contre l'utilisation de SP dans un environnement à 3 niveaux, où vous avez un serveur d'applications en face. Dans ce type d'environnement, votre serveur d'applications est là pour exécuter votre logique métier. Si vous utilisez également des SP, vous commencez à distribuer votre implémentation de la logique métier sur tout votre système et il deviendra très difficile de savoir qui est responsable de quoi. Finalement, vous vous retrouverez avec un serveur d'applications qui ne fera rien d'autre que ce qui suit:

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

Donc, à la fin, vous avez votre niveau intermédiaire en cours d'exécution sur ce cluster de 4 serveurs très cool, chacun d'eux équipé de 16 processeurs et cela ne fera rien du tout! Quel gâchis!

Si vous avez un gros client gui qui se connecte directement à votre base de données ou peut-être encore plus d'applications, c'est une autre histoire. Dans cette situation, les SP peuvent servir de pseudo-niveau intermédiaire qui dissocie votre application du modèle de données et offre un accès contrôlable.

Avantages pour dans Code:

• Plus facile à entretenir - pas besoin d'exécuter un script SQL pour mettre à jour les requêtes
• Port plus facile vers une autre base de données - aucun processus à porter

En fait, je pense que vous avez cela à l'envers. À mon humble avis, SQL dans le code est difficile à maintenir parce que:

• vous finissez par vous répéter dans des blocs de code associés
• SQL n'est pas pris en charge en tant que langage dans de nombreux IDE, vous n'avez donc qu'une série de chaînes vérifiées sans erreur effectuant des tâches pour vous
• les modifications d'un type de données, d'un nom de table ou d'une contrainte sont beaucoup plus courantes que l'échange d'une base de données entière pour une nouvelle
• votre niveau de difficulté augmente à mesure que votre requête se complexifie
• et tester une requête en ligne nécessite de construire le projet

Considérez les processus stockés comme des méthodes que vous appelez à partir de l'objet de base de données - ils sont beaucoup plus faciles à réutiliser, il n'y a qu'un seul endroit pour les modifier et si vous changez de fournisseur de base de données, les changements se produisent dans vos processus stockés et non dans votre code .

Cela dit, les gains de performances des procs stockés sont minimes comme Stu l'a dit avant moi et vous ne pouvez pas (encore) mettre un point d'arrêt dans une procédure stockée.

CON

Je trouve que faire beaucoup de traitement à l'intérieur des procédures stockées ferait de votre serveur DB un point d'inflexibilité unique, lorsqu'il s'agit de faire évoluer votre action.

Cependant, faire tout ce crunching dans votre programme par opposition au serveur sql, peut vous permettre de faire évoluer davantage si vous avez plusieurs serveurs qui exécutent votre code. Bien sûr, cela ne s'applique pas aux processus stockés qui effectuent uniquement la récupération ou la mise à jour normales, mais à ceux qui effectuent plus de traitement, comme le bouclage sur des ensembles de données.

AVANTAGES

1. Performance pour ce que cela peut valoir (évite l'analyse des requêtes par le pilote de base de données / recréation de plan, etc.)
2. La manipulation des données n'est pas intégrée dans le code C / C ++ / C #, ce qui signifie que j'ai moins de code de bas niveau à parcourir. SQL est moins détaillé et plus facile à parcourir lorsqu'il est répertorié séparément.
3. En raison de la séparation, les gens peuvent trouver et réutiliser le code SQL beaucoup plus facilement.
4. Il est plus facile de changer les choses lorsque le schéma change - vous n'avez qu'à donner la même sortie au code et cela fonctionnera très bien
5. Portage plus facile vers une autre base de données.
6. Je peux répertorier les autorisations individuelles sur mes procédures stockées et contrôler l'accès à ce niveau également.
7. Je peux profiler mon code de requête / persistance de données séparément de mon code de transformation de données.
8. Je peux implémenter des conditions modifiables dans ma procédure stockée et il serait facile de personnaliser sur un site client.
9. Il devient plus facile d'utiliser certains outils automatisés pour convertir mon schéma et mes instructions ensemble plutôt que lorsqu'il est intégré dans mon code où je devrais les traquer.
10. Il est plus facile de garantir les meilleures pratiques pour l'accès aux données lorsque vous avez tout votre code d'accès aux données dans un seul fichier - je peux vérifier les requêtes qui accèdent à la table non performante ou qui utilise un niveau de sérialisation plus élevé ou sélectionnez * dans le code, etc. .
11. Il devient plus facile de trouver des changements de schéma / changements de logique de manipulation de données lorsque tout cela est répertorié dans un seul fichier.
12. Il devient plus facile de rechercher et de remplacer les modifications sur SQL lorsqu'elles sont au même endroit, par exemple, changer / ajouter des instructions d'isolation de transaction pour tous les proc stockés.
13. Moi et le DBA trouvons qu'il est plus facile / pratique d'avoir un fichier SQL séparé lorsque le DBA doit revoir mes trucs SQL.
14. Enfin, vous n'avez pas à vous soucier des attaques par injection SQL car certains membres paresseux de votre équipe n'ont pas utilisé de requêtes paramétrées lors de l'utilisation de SQL intégrés.

L'avantage de performance pour les procédures stockées est souvent négligeable.

Plus d'avantages pour les procédures stockées:

• Empêcher l'ingénierie inverse (si créé avec chiffrement, bien sûr)
• Meilleure centralisation de l'accès aux bases de données
• Possibilité de changer le modèle de données de manière transparente (sans avoir à déployer de nouveaux clients); particulièrement pratique si plusieurs programmes accèdent au même modèle de données

Je tombe du côté du code . Nous construisons une couche d'accès aux données qui est utilisée par toutes les applications (Web et client), donc c'est SEC de ce point de vue. Cela simplifie le déploiement de la base de données car nous devons simplement nous assurer que les schémas de table sont corrects. Il simplifie la maintenance du code car nous n'avons pas à regarder le code source et la base de données.

Je n'ai pas beaucoup de problème avec le couplage étroit avec le modèle de données car je ne vois pas où il est possible de vraiment rompre ce couplage. Une application et ses données sont intrinsèquement couplées.

Procédures stockées.

Si une erreur glisse ou que la logique change un peu, vous n'avez pas à recompiler le projet. De plus, il permet d'accéder à partir de différentes sources, et pas seulement à l'endroit où vous avez codé la requête dans votre projet.

Je ne pense pas qu'il soit plus difficile de maintenir des procédures stockées, vous ne devez pas les coder directement dans la base de données mais dans des fichiers séparés d'abord, vous pouvez simplement les exécuter sur la base de données que vous devez configurer.

Avantages des procédures stockées :

Revue de code plus facile.

Moins couplé, donc plus facile à tester.

Plus facile à régler.

Les performances sont généralement meilleures, du point de vue du trafic réseau - si vous avez un curseur, ou similaire, il n'y a pas plusieurs trajets vers la base de données

Vous pouvez protéger l'accès aux données plus facilement, supprimer l'accès direct aux tables, renforcer la sécurité via les procs - cela vous permet également de trouver relativement rapidement tout code qui met à jour une table.

Si d'autres services sont impliqués (tels que les services de rapports), il peut être plus facile de stocker toute votre logique dans une procédure stockée, plutôt que dans du code, et d'avoir à la dupliquer

Désavantages:

Plus difficile à gérer pour les développeurs: contrôle de version des scripts: chacun a-t-il sa propre base de données, le système de contrôle de version est-il intégré à la base de données et à l'IDE?

Dans certaines circonstances, le SQL créé dynamiquement dans le code peut avoir de meilleures performances qu'un proc stocké. Si vous avez créé un proc stocké (disons sp_customersearch) qui devient extrêmement compliqué avec des dizaines de paramètres car il doit être très flexible, vous pouvez probablement générer une instruction sql beaucoup plus simple dans le code lors de l'exécution.

On pourrait dire que cela déplace simplement certains traitements de SQL vers le serveur Web, mais en général, ce serait une bonne chose.

L'autre avantage de cette technique est que si vous recherchez dans le profileur SQL, vous pouvez voir la requête que vous avez générée et la déboguer beaucoup plus facilement que de voir un appel de proc stocké avec 20 paramètres entrer.

J'aime les proc stockés, je ne sais pas combien de fois j'ai pu apporter une modification à une application en utilisant une procédure stockée qui n'a produit aucun temps d'arrêt pour l'application.

Grand fan de Transact SQL, le réglage de grandes requêtes s'est avéré très utile pour moi. Je n'ai pas écrit de SQL en ligne depuis environ 6 ans!

Vous listez 2 pro-points pour les sprocs:

Performance - pas vraiment. Dans Sql 2000 ou supérieur, les optimisations du plan de requête sont plutôt bonnes et mises en cache. Je suis sûr qu'Oracle etc. fait des choses similaires. Je ne pense plus que les sprocs soient plus performants.

Sécurité? Pourquoi les sprocs seraient-ils plus sûrs? À moins que vous n'ayez une base de données assez non sécurisée, tout l'accès se fera à partir de vos DBA ou via votre application. Paramétrez toujours toutes les requêtes - n'insérez jamais quelque chose à partir de la saisie de l'utilisateur et tout ira bien.

C'est de toute façon la meilleure pratique pour la performance.

Linq est définitivement la façon dont j'irais sur un nouveau projet en ce moment. Voir cet article similaire .

@Keith

Sécurité? Pourquoi les sprocs seraient-ils plus sûrs?

Comme suggéré par Komradekatz, vous pouvez interdire l'accès aux tables (pour le combo nom d'utilisateur / mot de passe qui se connecte à la base de données) et autoriser uniquement l'accès au SP. De cette façon, si quelqu'un obtient le nom d'utilisateur et le mot de passe dans votre base de données, il peut exécuter des SP mais ne peut pas accéder aux tables ou à toute autre partie de la base de données.

(Bien sûr, l'exécution de sprocs peut leur donner toutes les données dont ils ont besoin, mais cela dépendrait des sprocs qui étaient disponibles. Leur donner accès aux tables leur donne accès à tout.)

Pense-y de cette façon

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

Je préfère les proc stockés

Il est également plus facile de faire des tests de performances par rapport à un proc, de le mettre dans l'analyseur de requêtes set statistics io / time sur set showplan_text on et le tour est joué

pas besoin d'exécuter le profileur pour voir exactement ce qu'on appelle

juste mes 2 cents

Je préfère les conserver dans le code (en utilisant un ORM, pas en ligne ou ad-hoc) afin qu'ils soient couverts par le contrôle de source sans avoir à gérer l'enregistrement des fichiers .sql.

De plus, les procédures stockées ne sont pas intrinsèquement plus sécurisées. Vous pouvez écrire une mauvaise requête avec un sproc aussi facilement qu'en ligne. Les requêtes en ligne paramétrées peuvent être tout aussi sécurisées qu'un sproc.

Utilisez votre code d'application comme ce qu'il fait le mieux: gérer la logique.
Utilisez votre base de données pour ce qu'elle fait le mieux: stocker des données.

Vous pouvez déboguer des procédures stockées, mais vous trouverez plus facile à déboguer et à maintenir la logique dans le code. Habituellement, vous finirez par recompiler votre code chaque fois que vous modifiez le modèle de base de données.

Les procédures stockées avec des paramètres de recherche facultatifs sont également très inefficaces car vous devez spécifier à l'avance tous les paramètres possibles et les recherches complexes sont parfois impossibles car vous ne pouvez pas prédire combien de fois un paramètre va être répété dans la recherche.

En matière de sécurité, les procédures stockées sont beaucoup plus sécurisées. Certains ont fait valoir que tout accès se ferait de toute façon via l'application. Ce que beaucoup de gens oublient, c'est que la plupart des failles de sécurité proviennent de l'intérieur d'une entreprise. Pensez au nombre de développeurs qui connaissent le nom d'utilisateur et le mot de passe "masqués" de votre application?

De plus, comme MatthieuF l'a souligné, les performances peuvent être considérablement améliorées en raison de moins d'allers-retours entre l'application (que ce soit sur un ordinateur de bureau ou un serveur Web) et le serveur de base de données.

D'après mon expérience, l'abstraction du modèle de données par le biais de procédures stockées améliore également considérablement la maintenabilité. En tant que personne qui a dû maintenir de nombreuses bases de données dans le passé, c'est un tel soulagement lorsqu'il est confronté à un changement de modèle requis pour pouvoir simplement changer une procédure stockée ou deux et que le changement soit complètement transparent pour TOUTES les applications extérieures. Plusieurs fois, votre application n'est pas la seule à pointer vers une base de données - il existe d'autres applications, solutions de reporting, etc., donc traquer tous ces points affectés peut être un problème avec un accès ouvert aux tables.

Je mettrai également des vérifications dans la colonne plus pour mettre la programmation SQL entre les mains de ceux qui s'y spécialisent et pour les SP facilitant beaucoup l'isolement et le test / l'optimisation du code.

Le seul inconvénient que je vois est que de nombreuses langues ne permettent pas le passage des paramètres de table, donc le passage d'un nombre inconnu de données peut être ennuyeux, et certaines langues ne peuvent toujours pas gérer la récupération de plusieurs jeux de résultats à partir d'une seule procédure stockée (bien que le ce dernier ne rend pas les SP plus mauvais que le SQL inline à cet égard).

L'une des suggestions d'une session Microsoft TechEd sur la sécurité à laquelle j'ai assisté, pour passer tous les appels via des proc stockés et refuser l'accès directement aux tables. Cette approche a été présentée comme offrant une sécurité supplémentaire. Je ne sais pas si cela en vaut la peine juste pour la sécurité, mais si vous utilisez déjà des procs stockés, cela ne pourrait pas faire de mal.

Certainement plus facile à maintenir si vous le mettez dans une procédure stockée. S'il y a une logique difficile qui pourrait changer à l'avenir, c'est certainement une bonne idée de la mettre dans la base de données lorsque plusieurs clients se connectent. Par exemple, je travaille actuellement sur une application qui a une interface Web pour l'utilisateur final et une application de bureau administratif, qui partagent toutes deux une base de données (évidemment) et j'essaie de garder autant de logique que possible sur la base de données. Ceci est un parfait exemple du principe DRY .

Je suis fermement du côté des proc stockés en supposant que vous ne trichez pas et n'utilisez pas de SQL dynamique dans le proc stocké. Premièrement, l'utilisation de procs stockés permet au dba de définir des autorisations au niveau du proc stocké et non au niveau de la table. Ceci est essentiel non seulement pour lutter contre les attaques par injection SQL, mais également pour empêcher les initiés d'accéder directement à la base de données et de changer les choses. C'est un moyen d'aider à prévenir la fraude. Aucune base de données contenant des informations personnelles (SSN, numéros de carte de crédit, etc.) ou qui crée de toute façon des transactions financières ne devrait être accessible, sauf par le biais de procédures hiérarchisées. Si vous utilisez une autre méthode, vous laissez votre base de données grande ouverte aux particuliers de l'entreprise pour créer de fausses transactions financières ou voler des données qui peuvent être utilisées pour le vol d'identité.

Les proc stockés sont également beaucoup plus faciles à maintenir et à optimiser les performances que le SQL envoyé depuis l'application. Ils permettent également à la base de données de voir quel sera l'impact d'un changement structurel de base de données sur la façon d'accéder aux données. Je n'ai jamais rencontré un bon dba qui permettrait un accès dynamique à la base de données.

Nous utilisons des procédures stockées avec Oracle DB où je travaille maintenant. Nous utilisons également Subversion. Toutes les procédures stockées sont créées en tant que fichiers .pkb & .pks et enregistrées dans Subversion. J'ai déjà fait du SQL en ligne et c'est pénible! Je préfère de beaucoup la façon dont nous le faisons ici. Créer et tester de nouvelles procédures stockées est beaucoup plus facile que de le faire dans votre code.

Il y a un

Journaux plus petits

Un autre pro mineur pour les procédures stockées qui n'a pas été mentionné: en ce qui concerne le trafic SQL, l'accès aux données basé sur sp génère beaucoup moins de trafic. Cela devient important lorsque vous surveillez le trafic pour l'analyse et le profilage - les journaux seront beaucoup plus petits et lisibles.

Je ne suis pas un grand fan des procédures stockées, mais je les utilise dans une condition:

Lorsque la requête est assez volumineuse, il est préférable de la stocker dans la base de données en tant que procédure stockée au lieu de l'envoyer à partir du code. De cette façon, au lieu d'envoyer d'énormes quantités de caractères de chaîne du serveur d'applications à la base de données, seule la "EXEC SPNAME"commande sera envoyée.

Ceci est exagéré lorsque le serveur de base de données et le serveur Web ne sont pas sur le même réseau (par exemple, la communication Internet). Et même si ce n'est pas le cas, trop de stress signifie beaucoup de bande passante gaspillée.

Mais mec, ils sont si terribles à gérer. Je les évite autant que possible.

Un proc stocké SQL n'augmente pas les performances de la requête

Bien évidemment, l'utilisation de procédures stockées présente plusieurs avantages par rapport à la construction de SQL dans du code.

1. Votre implémentation de code et SQL deviennent indépendants l'un de l'autre.
2. Le code est plus facile à lire.
3. Écrivez une fois, utilisez plusieurs fois.
4. Modifier une fois
5. Pas besoin de donner des détails internes au programmeur sur la base de données. etc.

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 finissez par réutiliser du code SQL.

La répétition de code est la pire chose que vous puissiez faire lorsque vous essayez de créer une application maintenable!

Que se passe-t-il lorsque vous trouvez une erreur logique qui doit être corrigée à plusieurs endroits? Vous êtes plus susceptible d'oublier de changer ce dernier endroit où vous copiez et collez votre code.

À mon avis, les gains de performances et de sécurité sont un atout supplémentaire. Vous pouvez toujours écrire des procédures stockées SQL non sécurisées / inefficaces.

Port plus facile vers une autre base de données - aucun processus à porter

Il n'est pas très difficile d'écrire toutes vos procédures stockées pour la création dans une autre base de données. En fait - c'est plus facile que d'exporter vos tables car il n'y a pas de clé primaire / étrangère à craindre.

@Terrapin - les sprocs sont tout aussi vulnérables aux attaques par injection. Comme j'ai dit:

Paramétrez toujours toutes les requêtes - n'insérez jamais quelque chose à partir de la saisie de l'utilisateur et tout ira bien.

Cela vaut pour les sprocs et Sql dynamique.

Je ne suis pas sûr que ne pas recompiler votre application soit un avantage. Je veux dire, vous avez exécuté vos tests unitaires contre ce code (à la fois l'application et la base de données) avant de recommencer à vivre de toute façon.

@Guy - oui, vous avez raison, les sprocs vous permettent de contrôler les utilisateurs de l'application afin qu'ils ne puissent effectuer que le sproc, pas l'action sous-jacente.

Ma question serait: si tous les accès via votre application, en utilisant des connexions et des utilisateurs avec des droits limités de mise à jour / insertion, etc., ce niveau supplémentaire ajoute-t-il de la sécurité ou une administration supplémentaire?

Mon opinion est bien celle-ci. S'ils ont compromis votre application au point où ils peuvent la réécrire, ils peuvent utiliser de nombreuses autres attaques.

Les injections SQL peuvent toujours être effectuées contre ces sprocs si elles incorporent dynamiquement du code, de sorte que la règle d'or s'applique toujours, toutes les entrées utilisateur doivent toujours être paramétrées.

Quelque chose que je n'ai pas vu mentionné jusqu'à présent: les personnes qui connaissent le mieux la base de données ne sont pas toujours celles qui écrivent le code de l'application. Les procédures stockées donnent aux gens de la base de données un moyen de s'interfacer avec des programmeurs qui ne veulent pas vraiment en savoir autant sur SQL. Les bases de données volumineuses - et en particulier héritées - ne sont pas les choses les plus faciles à comprendre complètement, de sorte que les programmeurs pourraient simplement préférer une interface simple qui leur donne ce dont ils ont besoin: laissez les administrateurs de base de données comprendre comment joindre les 17 tables pour y arriver.

Cela étant dit, les langages utilisés pour écrire des procédures stockées (PL / SQL étant un exemple notoire) sont assez brutaux. Ils n'offrent généralement aucune des subtilités que vous verriez dans les langages impératifs, POO ou fonctionnels populaires d'aujourd'hui. Pensez COBOL.

Donc, respectez les procédures stockées qui résument simplement les détails relationnels plutôt que celles qui contiennent la logique métier.

J'écris généralement du code OO. Je soupçonne que la plupart d'entre vous le font probablement aussi. Dans ce contexte, il me semble évident que toute la logique métier - y compris les requêtes SQL - appartient aux définitions de classe. Diviser la logique de telle sorte qu'une partie de celle-ci réside dans le modèle d'objet et qu'une partie se trouve dans la base de données n'est pas mieux que de mettre la logique métier dans l'interface utilisateur.

Beaucoup de choses ont été dites dans les réponses précédentes sur les avantages de sécurité des procs stockés. Ceux-ci se répartissent en deux grandes catégories:

1) Restreindre l'accès direct aux données. C'est certainement important dans certains cas et, lorsque vous en rencontrez un, les proc stockés sont à peu près votre seule option. D'après mon expérience, de tels cas sont toutefois l'exception plutôt que la règle.

2) Injection SQL / requêtes paramétrées. Cette objection est un hareng rouge. Le SQL en ligne - même le SQL en ligne généré dynamiquement - peut être aussi complètement paramétré que n'importe quel proc stocké et cela peut être fait aussi facilement dans n'importe quel langage moderne qui en vaut la peine. Il n'y a aucun avantage de toute façon ici. ("Les développeurs paresseux pourraient ne pas se soucier d'utiliser des paramètres" n'est pas une objection valable. Si vous avez des développeurs dans votre équipe qui préfèrent simplement concaténer les données utilisateur dans leur SQL au lieu d'utiliser des paramètres, vous essayez d'abord de les éduquer, puis vous les déclenchez si cela ne fonctionne pas, tout comme vous le feriez avec des développeurs qui ont une autre mauvaise habitude manifestement préjudiciable.)

Je suis un grand partisan du code sur SPROC. La première raison est de garder le code étroitement couplé, puis la seconde est la facilité de contrôle des sources sans beaucoup d'utilitaires personnalisés pour le tirer.

Dans notre DAL, si nous avons des instructions SQL très complexes, nous les incluons généralement en tant que fichiers de ressources et les mettons à jour selon les besoins (cela pourrait également être un assembly séparé, et échangé par db, etc ...).

Cela conserve notre code et nos appels sql stockés dans le même contrôle de version, sans "oublier" d'exécuter certaines applications externes pour la mise à jour.