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

https://stackoverflow.com/questions/15142

08-06-2019
|

Question

Quels sont les avantages/inconvénients de conserver SQL dans votre code source C# ou dans les procédures stockées ?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 des accès à la base de données se font en créant le SQL en ligne en C# et en appelant la base de données SQL Server.J'essaie donc d'établir lequel, pour ce projet particulier, serait le meilleur.

Jusqu'à présent j'ai :

Avantages pour le code :

Plus facile à maintenir - pas besoin d'exécuter un script SQL pour mettre à jour les requêtes
Plus facile à porter vers une autre base de données - pas de procédure à porter

Avantages pour les processus stockés :

Performance
Sécurité

La solution

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

De toute façon, vous finirez par le recompiler lorsque les types de données changeront, ou si vous souhaitez renvoyer une colonne supplémentaire, ou autre.Le nombre de fois où vous pouvez modifier « de manière transparente » le code SQL depuis le dessous de votre application est globalement assez faible.

Vous finissez par réutiliser le code SQL.

Les langages de programmation, y compris C#, ont cette chose étonnante, appelée fonction.Cela signifie que vous pouvez appeler le même bloc de code à partir de plusieurs endroits !Incroyable!Vous pouvez ensuite insérer le code SQL réutilisable dans l'un d'entre eux, ou si vous souhaitez obtenir une technologie vraiment high-tech, vous pouvez utiliser une bibliothèque qui le fait pour vous.Je crois qu'ils s'appellent des mappeurs relationnels objet et qu'ils 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 procédures stockées 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...des blocs de SQL ?

Vous avez 4 serveurs Web et un tas d'applications Windows qui utilisent le même code SQL. Maintenant, vous réalisez qu'il y a un petit problème avec le code SQL, alors faites-vous plutôt......changez le processus en un seul endroit ou envoyez le code à tous les serveurs Web, réinstallez toutes les applications de bureau (un clic peut aider) sur toutes les 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 cela 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 « modifications poussées » affectent le code et non la base de données.Si vous envoyez 20 éléments aux serveurs Web ce mois-là et 1 à la base de données, vous ne perdez pas grand-chose si vous envoyez plutôt 21 éléments aux serveurs Web et zéro à la base de données.

Code plus facilement révisé.

Pouvez-vous expliquer comment ?Je ne comprends pas.D'autant plus que 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 d'inconvénients :

Les procédures stockées résident 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 sous contrôle de code source deviennent un cauchemar.

Il y a aussi la question de l’effort.Il pourrait être judicieux de tout décomposer en un millions de niveaux si vous essayez de justifier auprès de votre PDG pourquoi cela lui a coûté 7 millions de dollars pour créer des forums, mais sinon, créer un processus stocké pour chaque petite chose n'est qu'un travail supplémentaire sans aucun avantage.

Autres conseils

Ceci est actuellement discuté sur quelques autres fils de discussion ici.Je suis un partisan constant des procédures stockées, même si de bons arguments en faveur de Linq to Sql sont présentés.

L'intégration de requêtes dans votre code vous lie étroitement à votre modèle de données.Les procédures stockées sont une bonne forme de programmation contractuelle, ce qui signifie qu'un administrateur de base de données a la liberté de modifier le modèle de données et le code de 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] En voici un 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 devant.Dans ce type d'environnement, votre serveur d'applications est là pour exécuter votre logique métier.Si vous utilisez en plus des SP, vous commencez à distribuer votre implémentation de logique métier dans 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 essentiellement que ce qui suit :

(Pseudocode)

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

Donc, au final, votre niveau intermédiaire fonctionne sur ce cluster de 4 serveurs très cool, chacun étant équipé de 16 processeurs et il ne fera en réalité rien du tout !Quel gâchis!

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

Avantages pour le code :

Plus facile à maintenir - pas besoin d'exécuter un script SQL pour mettre à jour les requêtes

Plus facile à porter vers une autre base de données - pas de procédure à porter

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

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 disposez donc simplement d'une série de chaînes vérifiées sans erreur qui effectuent des tâches à votre place.
les modifications d'un type de données, d'un nom de table ou d'une contrainte sont bien plus fréquentes que le remplacement d'une base de données entière par une nouvelle
votre niveau de difficulté augmente à mesure que votre requête gagne en complexité
et tester une requête en ligne nécessite de construire le projet

Considérez les procédures stockées comme des méthodes que vous appelez à partir de l'objet de base de données : elles 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 modifications se produisent dans vos procédures stockées et non dans votre code. .

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

ESCROQUER

Je trouve que faire beaucoup de traitements dans des procédures stockées ferait de votre serveur de base de données un point de rigidité unique lorsqu'il s'agit de faire évoluer votre action.

Cependant, en faisant tout cela dans votre programme par opposition au serveur SQL, pourrait vous permettent d'évoluer davantage si vous disposez de 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 normale, mais à ceux qui effectuent davantage de traitements, comme la boucle sur des ensembles de données.

AVANTAGES

Performances pour ce qu'elles peuvent valoir (évite l'analyse des requêtes par le pilote DB / plan de récréation, etc.)
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 verbeux et plus facile à parcourir lorsqu'il est répertorié séparément.
Grâce à la séparation, les utilisateurs peuvent trouver et réutiliser le code SQL beaucoup plus facilement.
Il est plus facile de changer les choses lorsque le schéma change - il vous suffit de donner le même résultat au code et cela fonctionnera très bien.
Plus facile à porter vers une autre base de données.
Je peux répertorier les autorisations individuelles sur mes procédures stockées et contrôler également l'accès à ce niveau.
Je peux profiler mon code de requête/persistance de données séparément de mon code de transformation de données.
Je peux implémenter des conditions modifiables dans ma procédure stockée et il serait facile de la personnaliser sur un site client.
Il devient plus facile d'utiliser certains outils automatisés pour convertir mon schéma et mes instructions ensemble plutôt que lorsqu'ils sont intégrés dans mon code où je devrais les traquer.
Garantir les meilleures pratiques pour l'accès aux données est plus facile 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 celle qui utilise un niveau de sérialisation plus élevé ou sélectionner des * dans le code, etc. .
Il devient plus facile de trouver les modifications de schéma/les modifications de logique de manipulation des données lorsque tout cela est répertorié dans un seul fichier.
Il devient plus facile de rechercher et de remplacer des modifications sur SQL lorsqu'elles se trouvent au même endroit, par exemple.modifier/ajouter des instructions d'isolation de transaction pour tous les processus stockés.
Moi et le gars du DBA trouvons qu'avoir un fichier SQL séparé est plus facile/pratique lorsque le DBA doit examiner mes éléments SQL.
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 en termes de performances des 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 cryptage, bien sûr)
Meilleure centralisation de l'accès aux bases de données
Possibilité de changer de 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 sur le code côté.Nous construisons une couche d'accès aux données qui est utilisée par toutes les applications (à la fois Web et client), donc c'est SEC de ce point de vue.Cela simplifie le déploiement de la base de données car il suffit de s'assurer que les schémas de table sont corrects.Cela simplifie la maintenance du code car nous n'avons pas besoin de 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 si la logique change un peu, vous n'avez pas besoin de recompiler le projet.De plus, il permet l'accès à partir de différentes sources, et pas seulement du seul 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 d'abord dans des fichiers séparés, vous pouvez ensuite simplement les exécuter sur la base de données que vous devez configurer.

Avantages pour les procédures stockées:

Code plus facilement révisé.

Moins couplé, donc plus facilement testé.

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 déplacements 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 procédures - 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 reporting), il vous sera peut-être plus facile de stocker toute votre logique dans une procédure stockée, plutôt que dans du code, et de devoir la dupliquer.

Désavantages:

Plus difficile à gérer pour les développeurs :contrôle de version des scripts :Est-ce que chacun a 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, un SQL créé dynamiquement dans le code peut avoir de meilleures performances qu'un processus stocké.Si vous avez créé un processus 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 au moment de l'exécution.

On pourrait affirmer que cela déplace simplement une partie du traitement 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 proc stocké avec 20 paramètres entrer.

J'aime les procédures stockées, je ne sais pas combien de fois j'ai pu apporter une modification à une application à l'aide d'une procédure stockée qui n'a entraîné aucun temps d'arrêt de l'application.

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

Vous listez 2 points positifs pour les sprocs :

Performances – 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. font des choses similaires.Je ne pense plus qu'il soit nécessaire d'utiliser des sprocs pour améliorer les performances.

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

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

Linq est définitivement la façon dont je me lancerais dans un nouveau projet en ce moment.Regarde ça article similaire.

@Keith

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

Comme suggéré par Komradekatz, vous pouvez interdire l'accès aux tables (pour la combinaison 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 de votre base de données, il peut exécuter les 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 fournir toutes les données dont ils ont besoin, mais cela dépendra des sprocs 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 que vous avez réalisé qu'il y avait un petit problème avec le code SQL alors plutôt ......Modifiez le Proc en 1 place ou poussez le code vers tous les serveurs Web, réinstallez toutes les applications de bureau (ClickOnce pourrait vous aider) sur toutes les boîtes Windows

Je préfère les processus stockés

Il est également plus facile de faire des tests de performances contre un proc, le mettre dans des statistiques de définition de l'analyseur de requête io / temps sur le jeu showplan_text sur et le tour est joué

pas besoin d'exécuter le profileur pour voir exactement comment on l'appelle

juste mes 2 centimes

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 à sauvegarder les 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'une procédure.

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

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

De plus, les procédures stockées avec des paramètres de recherche facultatifs sont très inefficaces car vous devez spécifier à l'avance tous les paramètres possibles et les recherches complexes ne sont parfois pas possibles 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 de toute façon, tous les accès se feraient 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 « cachés » de votre application ?

De plus, comme l'a souligné MatthieuF, les performances peuvent être considérablement améliorées grâce à la diminution des 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 via des procédures stockées améliore également considérablement la maintenabilité.En tant que personne ayant dû gérer de nombreuses bases de données dans le passé, c'est un tel soulagement, confronté à un changement de modèle requis, de pouvoir simplement modifier une ou deux procédures stockées et que le changement soit complètement transparent pour TOUTES les applications extérieures.Souvent, votre application n'est pas la seule à pointer vers une base de données : il existe d'autres applications, solutions de reporting, etc.donc retrouver tous ces points concernés peut être compliqué avec un accès ouvert aux tables.

Je mettrai également des coches dans la colonne plus pour mettre la programmation SQL entre les mains de ceux qui s'y spécialisent, et pour les SP, ce qui rend beaucoup plus facile l'isolation et le test/optimisation du code.

Le seul inconvénient que je vois est que de nombreux langages ne permettent pas la transmission de paramètres de table, donc transmettre un nombre inconnu de valeurs de données peut être ennuyeux, et certains langages 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 pires que le SQL en ligne à cet égard).

L'une des suggestions d'une session Microsoft TechEd sur la sécurité à laquelle j'ai assisté, consiste à passer tous les appels via des procédures stockées 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 uniquement pour des raisons de sécurité, mais si vous utilisez déjà des procédures stockées, cela ne pourrait pas faire de mal.

Certainement plus facile à maintenir si vous le mettez dans une procédure stockée.S'il existe 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 possède une interface Web d'utilisateur final et une application de bureau administrative, qui partagent toutes deux une base de données (évidemment) et j'essaie de conserver autant de logique que possible sur la base de données.C'est un exemple parfait de Principe SEC.

Je suis fermement du côté des processus stockés en supposant que vous ne trichez pas et n'utilisez pas de SQL dynamique dans le processus stocké.Premièrement, l'utilisation de procédures stockées permet au dba de définir des autorisations au niveau des procédures stockées et non au niveau de la table.Ceci est essentiel non seulement pour lutter contre les attaques par injection SQL, mais aussi pour empêcher les initiés d'accéder directement à la base de données et de modifier les choses.C’est un moyen de contribuer à prévenir la fraude.Aucune base de données contenant des informations personnelles (SSN, numéros de carte de crédit, etc.) ou créant de quelque manière que ce soit des transactions financières ne devrait jamais être consultée sauf via des procédures stockées.Si vous utilisez une autre méthode, vous laissez votre base de données grande ouverte aux individus de l'entreprise pour créer de fausses transactions financières ou voler des données pouvant être utilisées pour le vol d'identité.

Les processus stockés sont également beaucoup plus faciles à maintenir et à ajuster les performances que le SQL envoyé depuis l'application.Ils permettent également au dba de voir quel sera l'impact d'un changement structurel de base de données sur la manière dont les données sont accessibles.Je n'ai jamais rencontré un bon administrateur de base de données qui permettrait un accès dynamique à la base de données.

Nous utilisons des procédures stockées avec les bases de données Oracle où je travaille actuellement.Nous utilisons également Subversion.Toutes les procédures stockées sont créées sous forme de fichiers .pkb et .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 loin la façon dont nous procédons ici.Créer et tester de nouvelles procédures stockées est beaucoup plus simple que de le faire dans votre code.

Il y a un

Bûches plus petites

Un autre avantage 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 traffic.Cela devient important lorsque vous surveillez le trafic à des fins d'analyse et de 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 sous forme de procédure stockée plutôt que 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, seuls les "EXEC SPNAME" la commande sera envoyée.

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

Mais mec, ils sont tellement terribles à gérer.Je les évite autant que je peux.

Un processus 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 le code.

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

Les procédures stockées sont PLUS maintenable car :

Vous n'avez pas besoin de recompiler votre application C# chaque fois que vous souhaitez modifier du SQL
Vous finissez par réutiliser le code SQL.

La répétition du code est la pire chose que vous pouvez 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 modifier le dernier endroit où vous copiez et collez votre code.

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

Plus facile à porter vers une autre base de données - pas de procédure à porter

Il n'est pas très difficile de scripter toutes vos procédures stockées pour les créer 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és primaires/étrangères à 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'incorporez jamais quelque chose à partir de l'entrée de l'utilisateur et tout ira bien.

Cela vaut pour les sprocs et le 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 sur ce code (à la fois l'application et la base de données) avant de remettre en ligne de toute façon.

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

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

Mon opinion est plutôt celle-ci.S'ils ont compromis votre application au point de pouvoir la réécrire, ils disposent de nombreuses autres attaques qu'ils peuvent utiliser.

Les injections SQL peuvent toujours être effectuées sur ces sprocs si elles intègrent dynamiquement du code, donc la règle d'or s'applique toujours, toutes les entrées de l'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 utilisateurs de bases de données un moyen d'interagir avec des programmeurs qui ne veulent pas vraiment en apprendre beaucoup sur SQL.Les bases de données volumineuses, et en particulier les anciennes, ne sont pas les choses les plus faciles à comprendre complètement, donc les programmeurs préféreront peut-être simplement une interface simple qui leur donne ce dont ils ont besoin :laissez les administrateurs de base de données déterminer comment rejoindre les 17 tables pour y parvenir.

Cela étant dit, les langages utilisés pour écrire des procédures stockées (PL/SQL en é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.

Alors, tenez-vous-en aux procédures stockées qui font simplement abstraction des détails relationnels plutôt qu'à celles qui contiennent une logique métier.

J'écris généralement du code OO.Je suppose 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 réside dans le modèle objet et une partie dans la base de données n'est pas mieux que d'insérer la logique métier dans l'interface utilisateur.

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

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

2) Injection SQL/requêtes paramétrées.Cette objection est une fausse piste.Le SQL en ligne - même le SQL en ligne généré dynamiquement - peut être tout aussi entièrement paramétré que n'importe quel processus stocké et cela peut être fait aussi facilement dans n'importe quel langage moderne digne de ce nom.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 licenciez si cela ne fonctionne pas, tout comme vous le feriez avec des développeurs qui ont d'autres développeurs. mauvaise habitude manifestement préjudiciable.)

Je suis un grand partisan du code plutôt que des SPROC.La première raison est de maintenir le code étroitement couplé, suivie de près par la facilité du contrôle des sources sans beaucoup d'utilitaires personnalisés pour l'extraire.

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 si nécessaire (cela peut également être un assemblage séparé et échangé par base de données, etc...).

Cela permet de conserver 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.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow