Procédures stockées: une mauvaise pratique dans l’une des plus grandes sociétés de conseil en logiciels informatiques?

148

Je travaille sur l'un des 3 plus grands cabinets de conseil en informatique du monde. Un administrateur de base de données m'a dit que les procédures stockées selon les meilleures pratiques de l'entreprise ne sont pas des "meilleures pratiques". C'est tellement contraire à tout ce que j'ai appris.

Les procédures stockées vous permettent de réutiliser le code et l’encapsulation (deux piliers du développement logiciel), la sécurité (vous pouvez accorder / révoquer des autorisations sur un processus stocké individuel), vous protéger des attaques par injection SQL et vous aider également à gagner du temps (bien que le DBA ait déclaré à partir de SQL Server 2008, même les requêtes SQL habituelles sont compilées si elles sont exécutées suffisamment de temps).

Nous développons une application complexe utilisant la méthodologie de développement logiciel Agile. Quelqu'un peut-il penser aux bonnes raisons pour lesquelles il ne souhaite pas utiliser de procs stockées? J'imaginais que les administrateurs de base de données ne voulaient pas conserver ces processus stockés, mais il semble y avoir trop de points négatifs pour justifier une telle décision de conception.

utilisateur673740
la source
3
Quelle réutilisation de code ajoute-t-il? Et si votre client utilise une base de données différente. Il faut éliminer tous ces SP et repartir de zéro. Ne vous protège pas contre l'injection sql. La vitesse est minime dans la plupart des cas.
Rig
32
N'oubliez pas que la plupart des grands cabinets de conseil en informatique ont pour motif de maximiser les heures facturables tout en gardant le cul couvert. Les anciens qui ont du poids dans ces entreprises ont également tendance à être des joueurs et des bureaucrates plutôt que des techniciens. Je prendrais des choses de ce genre dans un cabinet de consultants avec un grain de sel - j'ai sorti les bureaux de consultants de la merde à plus d'une occasion en améliorant leurs "meilleures" pratiques.
ConcernedOfTunbridgeWells
1
La réutilisation du code @Rig est ajoutée comme pour les fonctions de toutes les langues - en enveloppant le code dans un conteneur réutilisable. Les procédures stockées vous protègent en fait de l'injection SQL tant que vous n'exécutez pas la chaîne que vous avez construite. Dire que la vitesse est minimale semble tout simplement inculte. La plupart des cas ne tomberont pas dans les mêmes catégories sur les avantages de performance, mais montrent une grande disparité.
Garet Claborn
1
@GaretClaborn Mais il est beaucoup plus probable de réorganiser la couche application que des années et des années de données de base de données historiques. Sur toute application d'application non triviale quand même. Et si vous le faites, vous passerez des mois à porter du code riche de procédure stockée. Ajouter une dépendance supplémentaire à votre projet présente peu d'avantages, sauf dans des situations critiques. Celles-ci existent, mais la plupart du temps, il ne s'agit que d'ajouter un obstacle supplémentaire à l'agilité du projet et à la réutilisation du code.
Rig
2
Venant d’un contexte où nous utilisions presque exclusivement sps, je peux vous dire l’avantage de s’éloigner d’eux et d’utiliser un ORM comme Entity Framework. Bien trop souvent, la logique métier est encapsulée dans la procédure. Alors que vous pouvez version procs avec certains outils de travail et ou tiers. Ce n'est pas aussi facile que cela serait dans un cadre tel que TFS ou GIT. Votre code de base de données émis est indépendant de votre fournisseur de SGBDR. Ainsi, vous pouvez changer de fournisseur de SGBDR à une date ultérieure avec moins de maux de tête.
ewahner

Réponses:

280

Dans mon expérience de travail sur de très grands projets, vous devez être très clair sur l'emplacement de la logique métier. Si vous autorisez un environnement dans lequel des développeurs individuels peuvent placer la logique métier dans la couche d'objet métier ou dans une procédure stockée comme bon leur semble, une application volumineuse devient TRÈS difficile à comprendre et à gérer.

Les procédures stockées sont idéales pour accélérer certaines opérations de base de données. Ma décision architecturale est de laisser toute la logique dans la couche de gestion de l'application et d'utiliser les procédures stockées de manière ciblée pour améliorer les performances lorsque l'analyse comparative indique qu'elle est justifiée.

Eric J.
la source
37
Je ne vois pas les choses aussi simplement. Pour moi, c'est toute la logique commerciale. La base de données, avec ou sans procédures stockées, fournit certains services et offre certaines garanties. Idéalement, il devrait être impossible qu'un code d'application incorrect mette la base de données dans un état incohérent. Si des procédures stockées sont nécessaires pour maintenir cette cohérence, je les utilise.
Kevin Cline
12
@kevin cline: Définit "l'état incohérent". Je conviens que les fonctionnalités de base de données telles que l'intégrité référentielle sont précieuses et réduisent considérablement le risque d'erreur d'application causant de graves dommages. Cependant, en règle générale, la définition de "données cohérentes" dépend de l'exécution correcte des règles de gestion.
Eric J.
16
ajoutez mon million au million de Mayo. La logique métier distribuée vous fait sortir de la voie de la bonne pratique et vous mène directement dans la voie de la folie
Nico
27
+1 La logique métier qui s'infiltre dans le DAL est une préoccupation majeure lors de l'utilisation de procédures stockées.
Système
30
@ ChristopherMahan, je ne voudrais JAMAIS utiliser une base de données que vous concevez. C'est la pire pratique possible du point de vue de la base de données. Les bases de données sont souvent directement affectées à la base de données. Il est imprévoyant de penser que quelqu'un utilisera la couche de gestion pour mettre à jour un million d'enregistrements ou d'autres événements qui se produisent avec le temps. Les importations ne passent généralement pas par la couche de gestion (oui, je veux traiter mes 21 millions d’importations d’enregistrements, un enregistrement à la fois dans la couche de gestion). La fraude est beaucoup plus facile lorsque vous n'avez pas de contraintes au niveau de la base de données. Les données erronées sont presque sûres à 100%.
HLGEM
163

Quelques observations

Les procédures stockées vous permettent de réutiliser le code et de l’encapsuler (deux piliers du développement logiciel),

Seulement si vous les utilisez correctement dans le contexte dans lequel elles sont censées être utilisées. On peut dire la même chose à propos des fonctions (en programmation structurée) ou des méthodes (en programmation orientée objet), et pourtant, nous voyons des fonctions 1K et des objets méga-ass.

Les artefacts ne vous donnent pas ces avantages. L'utilisation appropriée de ces artefacts est ce qui confère ces avantages.

sécurité (vous pouvez accorder / révoquer des autorisations sur un proc stocké),

Oui. C'est un bon point et l'une des principales raisons pour lesquelles j'aime les procédures stockées. Ils fournissent un contrôle d'accès plus fin que ce que l'on peut généralement obtenir uniquement avec des vues et des comptes d'utilisateurs.

vous protéger des attaques par injection SQL,

Cela n’est pas spécifique aux SP car vous pouvez obtenir le même niveau de protection avec des instructions SQL paramétrées et un nettoyage d’entrée. J'utiliserais des SP en plus de ceux, cependant, en matière de "sécurité en profondeur" .

et aide également avec la rapidité (bien que le DBA ait dit qu'à partir de SQL Server 2008, même les requêtes SQL régulières soient compilées si elles sont exécutées suffisamment de fois).

Cela dépend fortement du fournisseur de base de données, mais en général, votre DBA a raison. Les instructions SQL (statiques ou paramétrées) sont compilées. Les SP peuvent vous aider si vous souhaitez / avez besoin d'agréger et de calculer des données que vous ne pouvez pas utiliser avec de simples instructions SQL, mais qui sont étroitement intégrées à SQL et ne garantissent pas l'aller-retour au serveur d'applications.

Un bon exemple consiste à interroger des données dans un curseur temporaire (ou des curseurs) à partir desquels exécuter un autre SQL lui-même. Vous pouvez le faire par programme dans le serveur d'applications, ou vous pouvez enregistrer les allers-retours multiples en le faisant dans la base de données.

Cela ne devrait cependant pas être la norme. Si vous avez beaucoup de cas, c'est un signe de mauvaise conception de la base de données (ou vous extrayez des données de schémas de base de données peu compatibles entre les départements.)

Nous développons une application complexe utilisant la méthodologie de développement logiciel Agile.

L'agilité concerne les processus d'ingénierie logicielle et la gestion des exigences, et non les technologies.

Quelqu'un peut-il penser aux bonnes raisons pour lesquelles il ne souhaite pas utiliser de procs stockées?

Mauvaise question

La question est fausse et équivaut à se demander "existe-t-il de bonnes raisons de ne pas utiliser GOTO"? Je suis plus du côté de Niklaus Wirth que de Dijkstra à ce sujet. Je peux comprendre d'où vient le sentiment de Dijkstra, mais je ne crois pas qu'il soit applicable à 100% dans tous les cas. Même chose avec les procs du magasin et n'importe quelle technologie.

Un outil est bon lorsqu'il est utilisé correctement et dans le but recherché. L’utiliser autrement ne signifie pas que l’outil est mauvais, mais que le porteur ne sait pas ce qu’il fait.

La bonne question est "quel type de modèles d'utilisation de procédures stockées doit être évité". Ou, "dans quelles conditions dois-je (ou ne pas) utiliser des procédures stockées" . Rechercher des raisons de ne pas utiliser une technologie revient simplement à blâmer l'outil plutôt qu'à placer la responsabilité de l'ingénieur clairement à l'endroit où elle se situe - dans l'ingénieur.

En d'autres termes, c'est une échappatoire ou une déclaration d'ignorance.

J'imaginais que les administrateurs de base de données ne voulaient pas conserver ces processus stockés, mais il semble y avoir trop de points négatifs pour justifier une telle décision de conception.

Ce qu'ils font alors, c'est projeter les résultats de leurs mauvaises décisions d'ingénierie sur les outils qu'ils ont mal utilisés.

Que faire dans votre cas?

Mon expérience est, quand à Rome, fais comme les Romains .

Ne le combat pas. Si les membres de votre entreprise souhaitent qualifier les procédures de magasin de mauvaises pratiques, laissez-les. Soyez avisé cependant que cela peut être un drapeau rouge dans leurs pratiques d'ingénierie.

L'étiquetage typique des choses comme étant une mauvaise pratique est généralement utilisé dans les organisations avec des tonnes de programmeurs incompétents. En faisant une liste noire de certaines choses, l’organisation tente de limiter les dommages causés en interne par leur propre incompétence. Je te chie pas.

Les généralisations sont la mère de tous les problèmes. Dire que les procs stockés (ou tout type de technologie) est une mauvaise pratique, c'est une généralisation. Les généralisations sont des échappatoires pour les incompétents. Les ingénieurs ne travaillent pas avec des généralisations flagrantes. Ils effectuent des analyses au cas par cas, effectuent des analyses de compromis et exécutent les décisions et solutions techniques en fonction des faits, dans le contexte dans lequel ils sont censés résoudre un problème.

Les bons ingénieurs n'affichent pas les choses comme de mauvaises pratiques de manière aussi générale. Ils examinent le problème, choisissent l'outil qui convient, font des compromis. En d'autres termes, ils font de l'ingénierie.

Mon avis sur comment ne pas les utiliser

  • Ne mettez pas de logique complexe au-delà de la collecte de données (et peut-être de certaines transformations). Il est correct d'y insérer une logique de traitement de données ou d'agréger le résultat de plusieurs requêtes. Mais c'est à peu près tout. Au-delà, cela constituerait une logique d’entreprise qui devrait résider ailleurs.

  • Ne les utilisez pas comme seul mécanisme de défense contre l’injection SQL. Vous les laissez là au cas où quelque chose de mauvais les gênerait , mais il devrait y avoir une série de logique défensive devant eux - validation / nettoyage côté client, validation / nettoyage côté serveur, éventuellement transformation en types qui ont un sens dans votre modèle de domaine, et finalement être passé à des instructions paramétrées (pouvant être des instructions SQL paramétrées ou des procédures stockées paramétrées).

  • Ne faites pas des bases de données le seul endroit contenant vos procs de magasin. Les procédures de votre magasin doivent être traitées de la même manière que votre code source C # ou Java. Autrement dit, le contrôle de source définit la définition textuelle de vos processus de magasin. Les gens disent que les processus des magasins ne peuvent pas être contrôlés à la source - bullcrap, ils ne savent tout simplement pas de quoi diable ils parlent.

Mon opinion sur comment / où les utiliser

  • Votre application nécessite des données qui doivent être transposées ou agrégées à partir de plusieurs requêtes ou vues. Vous pouvez décharger cela de l'application dans la base de données. Ici, vous devez faire une analyse de performance car a) les moteurs de base de données sont plus efficaces que les serveurs d'applications, mais b) les serveurs d'applications sont (parfois) plus faciles à faire évoluer horizontalement.

  • Contrôle d'accès au grain fin. Vous ne voulez pas qu'un idiot exécute des jointures cartésiennes dans votre base de données, mais vous ne pouvez pas simplement empêcher des personnes d'exécuter des instructions SQL arbitraires comme cela non plus. Une solution typique consiste à autoriser des instructions SQL arbitraires dans les environnements de développement et UAT, tout en les interdisant dans les environnements systest et de production. Toute déclaration qui doit parvenir à systest ou à la production va dans une procédure de magasin, révisée par le code à la fois par les développeurs et par dbas.

Tout besoin valide d'exécuter une instruction SQL qui ne se trouve pas dans un processus de magasin passe par un nom d'utilisateur / compte et un pool de connexions différents (l'utilisation est fortement surveillée et déconseillée).

  • Dans les systèmes comme Oracle, vous pouvez accéder à LDAP, ou créer des liens symboliques vers des bases de données externes (dire appeler un proc magasin sur db un partenaire commercial via vpn.) Un moyen facile de faire du code spaghetti, mais ce qui est vrai pour tous les paradigmes de programmation, et parfois vous avez des exigences commerciales / environnementales spécifiques pour lesquelles il s'agit de la seule solution. Store procs help encapsule cette méchanceté au même endroit, à proximité des données et sans passer par le serveur d'applications.

Que vous l'exécutiez sur la base de données en tant que procédure de magasin ou sur votre serveur d'applications dépend de l'analyse des compromis que vous devez effectuer en tant qu'ingénieur. Les deux options doivent être analysées et justifiées par un certain type d'analyse. Aller d'une manière ou d'une autre en accusant simplement l'autre solution de rechange est une "mauvaise pratique", c'est juste une échappatoire ingénieuse en ingénierie.

  • Dans les cas où vous ne pouvez tout simplement pas augmenter votre serveur d'applications (.... Aucun budget pour le nouveau matériel ou les instances de cloud), mais avec beaucoup de capacité sur le back-end de la base de données (c'est plus typique que beaucoup de gens veulent bien admettre), cela rapporte déplacer la logique métier pour stocker les procs. Pas beau et peut conduire à des modèles de domaine anémique ... mais encore une fois ... une analyse de compromis, la chose la plupart des hacks de logiciels sucent.

Que cela devienne une solution permanente ou non, c'est spécifique aux contraintes observées à ce moment particulier.

J'espère que ça aide.

luis.espinal
la source
14
C'est une très bonne réponse.
Yfeldblum
5
Bonne réponse, mais est-ce que cela devait être ironique? "Les généralisations sont la mère de tous les problèmes."
bedwyr
2
Oui et non. Ce commentaire mien était destiné à cette phrase particulière référée par le PO dans sa question initiale ( les procédures stockées ne constituent pas une "meilleure pratique" .) Une description grossière des procédures en magasin en tant que meilleure ou mauvaise pratique est une généralisation. Ignorer le contexte dans lequel elles peuvent être bonnes OU mauvaises peut (et conduira souvent) à des erreurs lors de la conception ou de la conception de solutions;)
luis.espinal
7
+1 pour "L'étiquetage typique des choses comme étant une mauvaise pratique est généralement appliqué dans les organisations avec des tonnes de programmeurs incompétents." - été là-bas, vécu cela, y compris en me disant à la face par un responsable de développement qu'il pensait que j'avais une bonne solution pour un problème épineux, mais s'il était vu pour me permettre de le mettre en œuvre, cela ouvrirait les vannes pour le muppets.
Julia Hayward
1
@ Stéphane Vous avez raison. Cependant, je crois que ce que cette réponse essaie de transmettre est la tendance de certains groupes d'ingénieurs à excuser leur manque de connaissances ou d'analyse en faisant appel à la fiche de mauvaise pratique. La réponse pourrait voir une amélioration pour les plus inexpérimentés, cependant.
Cesar Hernandez
56

La raison en est que le recours à une couche de procédure stockée limite la portabilité et vous lie à une certaine base de données. Les coûts de maintenance ajoutés sont également cités comme raison. Je voulais aussi commenter ce que vous avez dit:

(procédures stockées) vous protège des attaques par injection SQL

C'est en fait l'interrogation paramétrée qui vous protège, ce que vous pouvez facilement faire avec l'interrogation SQL en texte brut.

System Down
la source
18
Et si votre procédure stockée utilise n’importe quel type de SQL dynamique avec un paramètre de chaîne, vous êtes de retour à votre point de départ.
JeffO
4
La différence réside dans le fait que l'autorisation d'accès peut être définie pour chaque procédure stockée. Pour les requêtes SQL paramétrées, vous devez vous fier au programmeur pour ne pas le faire + "blablabla"car vous devez autoriser le langage SQL simple, et c'est là que se termine le contrôle.
Coder
19
Je n'ai jamais compris l'argument "vous lie à un certain DB". À quelle fréquence prenez-vous votre programme et le migrez-vous vers une base de données entièrement différente?
Mason Wheeler
11
@MasonWheeler - +1 à chaque fois. Dans tout projet suffisamment important, votre application finit par être écrite contre les faiblesses d'un produit de base de données donné. La conversion en une autre base de données devient un travail important, peu importe la situation, car la nouvelle base de données aura des particularités différentes!
Michael Kohne
6
@HLGEM - mais dans le monde COTS, plusieurs bases de données sont attendues au départ (en fait, vous choisissez les bases de données compatibles). Ce n'est pas que vous portez, c'est que vous supportez des serveurs différents, ce qui est une bête complètement différente de celle d'un portage.
Michael Kohne
46

Certaines des raisons pour lesquelles je conviens que les procédures stockées ne constituent pas une pratique exemplaire.

  • La logique métier et applicative doit figurer dans le code et non dans la base de données. Mettre de la logique dans la base de données est une source de confusion.
  • Vous ne pouvez pas tester les processus stockés de manière aussi transparente que le code dans vos projets de tests unitaires conventionnels avec le reste de la logique d'application.
  • Je ne trouve pas que les procédures stockées soient propices à tester la première programmation lorsque j'écris du code.
  • Les procédures stockées ne sont pas aussi faciles à déboguer que le code d'application lorsque vous déboguez votre programme dans votre IDE.
  • Contrôle de contrôle / contrôle de source du SP par rapport au code normal
Gilles
la source
7
Vous pouvez aussi facilement programmer des tests sur des procédures stockées.
5
Hmmm, bien ... 1) L'utilisation de procédures stockées de la base de données n'implique pas nécessairement que la logique métier y est mise. 2) Les procédures stockées sont parmi les choses les plus faciles à tester. 3) les processus de magasin ne conduisent pas nécessairement aux pratiques de test d’abord, certes, mais tout ce qui est calculable ne peut pas être testé d’abord. 4) le débogage ne devrait pas être un problème puisque les procédures de magasin ne devraient contenir que des instructions et des curseurs SQL faciles à vérifier. En outre, le débogage doit avoir lieu en testant et en déboguant les instructions SQL dans le code, puis déplacé dans les procédures de magasin ... juste IMO btw.
luis.espinal
6
Vous n'êtes évidemment pas un dev DB. Contrôle de la source, IDE - il est très facile de déboguer un SP si vous utilisez TOAD ou un IDE similaire, comme avec le contrôle de version.
gbjbaanb
6
2) sur les tests unitaires procs stockés. Idk sur les autres frameworks de test d'unité, mais au moins avec MS Test (VisualStudio.TestTools.UnitTesting), exécuter l'une des méthodes Assert sur le processus stocké nécessite au moins une connexion Db, ce qui par définition en fait plus un test d'intégration qu'une unité tester. Et un proc stocké peut faire référence à l'état de la base de données au niveau global. Ceux-ci peuvent ne pas être faux ou avoir des interfaces.
T. Webster
3
+1 En outre, les langages de procédures stockées (pl / sql, t-sql, plpgsql, etc.) sont très maladroits et très prolixes. Il est beaucoup plus facile pour moi d'utiliser un langage de script pour établir une connexion à une base de données et gérer la logique métier en dehors de la base de données.
22

Les procédures stockées vous permettent de réutiliser le code et de l’encapsuler (deux piliers du développement logiciel),

Oui, mais au prix de pouvoir atteindre d’autres objectifs de conception agiles. Ils sont plus difficiles à maintenir, d'une part. Si le projet auquel je participe est une indication, vous obtiendrez probablement plusieurs SP incompatibles qui font essentiellement le même travail, sans aucun avantage.

vous protéger des attaques par injection SQL,

Non, ils ne pas. Je ne peux même pas commencer à deviner d'où vient cette idée, comme je l'entends souvent, et ce n'est tout simplement pas vrai. Cela peut atténuer certains types d'attaques d'injection SQL, mais si vous n'utilisez pas de requêtes paramétrées, cela n'aura pas d'importance. Je peux encore '; DROP TABLE Comptes; -

et aide également avec la rapidité (bien que le DBA ait dit qu'à partir de SQL Server 2008, même les requêtes SQL régulières soient compilées si elles sont exécutées suffisamment de fois).

Ils sont également généralement compilés lorsque vous utilisez des instructions préparées et paramétrées (au moins avec plusieurs des bases de données que j'ai utilisées). Au moment où votre application commence à exécuter la requête (ou particulièrement lorsque vous exécutez plusieurs fois la même requête préparée), tout avantage en termes de performances dont dispose votre SP est totalement sans objet.

La seule raison d'utiliser une procédure stockée, IMHO, est lorsque vous devez créer une requête complexe à plusieurs étapes extraite de plusieurs sources assemblées. Les SP ne doivent pas contenir de logique de décision de bas niveau et ne doivent jamais simplement encapsuler une requête par ailleurs simple. Il n'y a pas d'avantages et seulement de nombreux inconvénients.

Écoutez votre DBA. Il sait ce qui se passe.

greyfade
la source
1
Red Gate a un produit Contrôle de source SQL pour SQL Server, mais je suis d'accord, l'insertion de la logique dans les procédures stockées est un excellent moyen de garantir que vous disposez d'une logique importante sans aucun contrôle de version.
Carson63000
17
@ Greyfade - "Je n'ai pas encore vu le contrôle de source pour les SP" - vous vous foutez de moi? Un processus de magasin est juste un fichier texte sanglant que vous téléchargez dans votre moteur de base de données (qui le prend, le compile et l'installe pour exécution). Chaque lieu où j'ai travaillé a stocké des procs, nous stockons le code source de la procédure de magasin, par exemple, CVS, clearcase ou tout autre SCM utilisé. Dire que les processus de magasin ne peuvent pas être contrôlés par la source (car ils sont dans la base de données) revient à dire que le code source de mon application (Java, C # ou autre) ne peut pas être contrôlé par la source car il est compilé et déployé en production.
luis.espinal
2
@ luis.espinal: je n'ai pas dit qu'ils ne pourraient pas être sous le contrôle de la source. J'ai simplement dit que je ne connaissais pas d'outil spécifique pour la maintenance de l'historique des fournisseurs de services, impliquant de la conserver dans la base de données. S'il vous plait, ne vous plaignez pas de moi juste parce que vous avez mal interprété quelque chose
Greyfade
1
Tous les processus stockés sont sous contrôle de source, simplement parce que vous avez déjà vu de mauvais protocoles dans le passé ne signifie pas qu'ils sont inhérents à l'utilisation de processus stockés.
HLGEM
1
@ luis.espinal est-il typique que la source d'une procédure stockée puisse être extraite ultérieurement de la base de données? Si c'est le cas, vous pouvez simplement disposer d'un outil qui le extrait régulièrement et d'un autre outil en place pour recréer une installation à partir de zéro. Faites-le de temps en temps pour vous assurer qu'il est exact.
17

C'était la ligne officielle lorsque j'ai travaillé pour l'un des Big Five il y a quelques années. La raison en était que, les SP étant liés à des implémentations particulières (PL / SQL vs T / SQL vs ...), ils limitaient inutilement les choix technologiques.

Ayant vécu la migration d’un grand système de T / SQL vers PL / SQL, je peux comprendre l’argument. Je pense cependant que c'est un peu canard - combien d'endroits passent réellement d'une base de données à une autre sur un coup de tête?

DaveE
la source
10
@DaveE: Pour une solution d'entreprise, vous avez probablement raison. Si vous créez un logiciel packagé, dès que vous expédiez MSSQL, votre plus gros client potentiel voudra qu'il s'exécute sur Oracle.
Eric J.
3
@ Eric: trop vrai. Là où je suis, nous utilisons des tonnes de SP et disons aux gens «non» s'ils ne veulent pas de MSSQL. C'est bien de pouvoir faire ça.
DaveE
3
@DaveE: L'équipe de vente souhaite-t-elle pouvoir dire "oui"?
Eric J.
2
Il ne s'agit pas autant de déplacer un système d'une base de données vers une autre, mais d'avoir un système capable d'utiliser le système de base de données que possède déjà le client. Les grandes bases de données coûtent cher.
@ EricJ: oui, mais une fois qu'ils ont vu ce que cela coûterait à leur commission, la demande disparaîtra un peu.
DaveE
17

Les trois entreprises sur lesquelles je travaille utilisent des procédures stockées utilisées pour leur logique d'application avec SQL Server. Je n'ai pas vraiment vu les choses dans l'autre sens. Mais pour moi, ils sont un gros bazar. Il n'y a généralement pas de très bonnes installations de traitement des erreurs ou des installations de réutilisation de code avec des procédures stockées.

Supposons que vous ayez une procédure stockée qui retourne un jeu de données que vous souhaitez utiliser. Comment pouvez-vous l'utiliser dans de futures procédures stockées? Les mécanismes sur SQL Server pour cela ne sont pas très bons. EXEC INTO ... ne fonctionne que sur un ou deux niveaux d’imbrication (je l’oublie maintenant). Ou vous devez prédéfinir une table de travail et la programmer en mode clé. Ou vous devez créer au préalable une table temporaire et la charger dans la procédure. Mais que se passe-t-il si deux personnes appellent une table temporaire la même chose dans deux procédures différentes qu’elles n’ont jamais envisagée d’utiliser en même temps? Dans n'importe quel langage de programmation normal, vous pouvez simplement renvoyer un tableau d'une fonction ou d'un point à un objet / une structure globale partagée entre eux (à l'exception des langages fonctionnels dans lesquels vous renverriez la structure de données plutôt que de changer une structure globale ... )

Que diriez-vous de la réutilisation de code? Si vous commencez à insérer des expressions courantes dans les fonctions UDF (ou même dans les requêtes secondaires), vous ralentirez le code. Vous ne pouvez pas appeler une procédure stockée pour effectuer un calcul pour une colonne (sauf si vous utilisez un curseur, transmettez les valeurs de colonne une par une, puis mettez à jour votre table / jeu de données d'une manière ou d'une autre). Donc, fondamentalement, pour obtenir le maximum de performances, vous devez couper / coller des expressions communes un peu partout, ce qui est un cauchemar de maintenance ... Avec un langage de programmation, vous pouvez créer une fonction pour générer le code SQL commun, puis l'appeler de partout lors de la construction. la chaîne SQL. Ensuite, si vous devez ajuster la formule, vous pouvez effectuer le changement en un seul endroit ...

Que diriez-vous de la gestion des erreurs? SQL Server contient de nombreuses erreurs qui empêchent immédiatement l'exécution de la procédure stockée et d'autres qui entraînent même une déconnexion. Depuis 2005, il y a try / catch mais il y a encore un certain nombre d'erreurs qui ne peuvent pas être capturées. De plus, la même chose se produit avec la duplication de code sur le code de traitement des erreurs et vous ne pouvez vraiment pas contourner les exceptions aussi facilement ou les réduire à des niveaux plus élevés aussi facilement que la plupart des langages de programmation .....

Aussi juste la vitesse. De nombreuses opérations sur les jeux de données ne sont pas orientées SET. Si vous essayez de faire des choses orientées ligne, vous utiliserez un curseur ou un "curseur" (lorsque les développeurs interrogent souvent chaque ligne et stockent le contenu dans des variables @, à la manière d'un curseur). Même si cela est souvent plus lent qu'un curseur FORWARD_ONLY). Avec SQL Server 2000, j'avais quelque chose qui fonctionnait pendant 1 heure avant de le tuer. J'ai réécrit ce code en Perl et tout s'est terminé en 20 minutes. Lorsqu'un langage de script qui est 20 à 80 fois plus lent que C fume le SQL en performance, vous n'avez absolument aucune activité commerciale d'écriture d'opérations orientées ligne dans SQL.

Désormais, SQL Server possède une intégration CLR et nombre de ces problèmes disparaissent si vous utilisez des procédures stockées CLR. Cependant, de nombreux administrateurs de bases de données ne savent pas écrire des programmes .NET ou désactiver le CLR pour des raisons de sécurité et s’en tenir à Transact SQL .... Même avec les CLR, vous rencontrez toujours des problèmes de partage efficace des données entre plusieurs procédures. .

Aussi, en général, la base de données est la chose la plus difficile à faire évoluer. Si toute votre logique métier est dans la base de données, vous rencontrerez des problèmes lorsque la base de données devient trop lente. Si vous avez une couche de gestion, vous pouvez simplement ajouter davantage de mémoire cache et davantage de serveurs d'entreprise pour améliorer les performances. Traditionnellement, un autre serveur pour installer Windows / Linux et exécuter .NET / Java coûte beaucoup moins cher que d’acheter un autre serveur de base de données et d’octroyer une licence supplémentaire à SQL Server. SQL Server prend désormais davantage en charge les clusters, mais à l’origine, il n’en avait pas vraiment. Donc, si vous avez beaucoup d’argent, vous pouvez ajouter des clusters ou même effectuer une expédition de journaux pour créer plusieurs copies en lecture seule. Mais dans l’ensemble, cela coûtera beaucoup plus que simplement avoir une écriture derrière le cache ou quelque chose du genre.

Examinez également les installations de Transact-SQL. Manipulation de chaîne? Je prendrai les classes Java String Class / Tokenizer / Scanner / Regex tous les jours. Tables de hachage / listes chaînées / etc. Je vais prendre les frameworks Java Collection, etc ... Et la même chose pour .NET ... C # et Java sont des langages beaucoup plus évolués que Transact SQL ... Le codage avec Heck de Transact-SQL me rend jaloux de C .. .

En plus, les procédures stockées sont plus efficaces pour travailler avec un grand jeu de données et appliquer plusieurs requêtes / critères pour le réduire avant de le renvoyer à la couche de gestion. Si vous devez envoyer un ensemble d'énormes ensembles de données à l'application client et décomposer les données sur le client, cela sera beaucoup plus inefficace que de simplement effectuer tout le travail sur le serveur.

Les procédures stockées sont également bonnes pour la sécurité. Vous pouvez couper tous les accès aux tables sous-jacentes et autoriser uniquement l'accès via les procédures stockées. Avec certaines techniques modernes telles que XML, vous pouvez avoir des procédures stockées qui effectuent des mises à jour par lots. Ensuite, tous les accès sont contrôlés via les procédures stockées. Ainsi, tant qu'elles sont sécurisées / correctes, les données peuvent avoir plus d'intégrité.

L'argument d'injection SQL ne s'applique plus vraiment depuis que nous avons paramétré des requêtes du côté du langage de programmation. De plus, même avant les requêtes paramétrées, un peu de remplacement ("'", "'" ") a également fonctionné la plupart du temps (bien qu'il reste encore des astuces à utiliser pour aller au-delà de la fin de la chaîne pour obtenir ce que vous voulez).

Globalement, je pense que SQL et Transact SQL sont d'excellents langages pour interroger / mettre à jour des données. Mais pour coder n'importe quel type de logique, manipuler des chaînes (ou manipuler des fichiers ... vous seriez surpris de ce que vous pouvez faire avec xp_cmdshell ...), veuillez ne pas. J'espère trouver un futur endroit qui n'utilise pas principalement de procédures stockées. Du point de vue de la maintenabilité du code, ils sont un cauchemar. De même, que se passera-t-il si vous souhaitez changer de plate-forme (bien que si vous payiez pour Oracle / DB2 / Sybase / SQL Server / etc.), Vous pouvez également obtenir tout ce dont vous avez besoin en utilisant toutes les extensions propriétaires qui peuvent vous aider. ..).

Aussi étonnamment souvent, la logique métier n’est pas la même. Dans un monde idéal, vous mettriez toute la logique dans les procédures stockées et la partageriez entre les applications. Mais très souvent, la logique varie en fonction des applications et vos procédures stockées finissent par devenir des monolithes trop complexes que les gens ont peur de changer et ne comprennent pas toutes les implications de. Tandis qu'avec un bon langage orienté objet, vous pouvez coder une couche d'accès aux données qui possède une interface / des raccords standard que chaque application peut remplacer selon ses propres besoins.

Cervo
la source
6
Je ne peux toutefois m'empêcher de proposer des pistes de réflexion sur l'ensemble de la question de la procédure par rapport à la procédure. J'ai vu des curseurs de base de données utilisés dans toutes sortes de cas où cette approche était complètement folle. J'ai personnellement remplacé le SQL explicite basé sur le curseur (Oracle PL / SQL, dans ce cas particulier) par une requête orientée ensemble et j'ai vu les résultats revenir en moins d'une seconde, au lieu de 8 minutes. Il m'a fallu 30 minutes pour disséquer ce code de curseur de 1 000 lignes et le "récupérer". La requête SQL résultante était concise, élégante et simple. Les gens sous-estiment trop souvent et trop rapidement la puissance de leurs serveurs de bases de données.
Craig
12

Comment versionnez-vous les procédures stockées sur le serveur?

Si vous redéployez des procédures stockées sur le serveur à partir du contrôle de version, vous supprimez le plan d'exécution stocké.

Les procédures stockées ne doivent pas être modifiables directement sur le serveur, sinon comment savoir ce qui se passe réellement correctement _ maintenant? S'ils ne le sont pas, l'outil de déploiement a besoin d'un accès pour écrire des procédures stockées dans la base de données. Vous devrez déployer sur chaque build (le plan de l'exécutif peut avoir besoin d'être différent)

Alors que les procédures stockées ne sont pas portables, SQL non plus (jamais vu oracle date manipulation - uggghhh).

Donc, si vous voulez la portabilité, créez une API d’accès aux données interne. Vous pouvez appeler cela comme des appels de fonction, et en interne, vous pouvez intégrer le jargon de votre choix, avec des requêtes paramétrées, et il peut être contrôlé par la version.

Christopher Mahan
la source
6
Comment versionnez-vous les procédures stockées sur le serveur? - vous contrôlez la version du code source de la boutique proc. Lorsque vient le temps de déployer, vous saisissez les procs du magasin (d'une base donnée) et vous (ou votre base de données) déployez en production. Le redéploiement (qu’il s’agisse de tests ou de production) annule le plan d’exécution stocké, mais cela se produira que vous contrôliez ou non votre SP.
luis.espinal
1
@BarryBrown Cela ne fonctionne pas si les utilisateurs ont directement accès au serveur et peuvent modifier les procédures stockées. Je devrais avoir un processus qui surveille les SP, ou avoir un contrôle avant chaque utilisation ...
Christopher Mahan
2
Si vous avez des personnes qui ne font que modifier les sprocs bon gré mal gré sur des serveurs sans valider leurs modifications dans le contrôle de source, vous avez un problème de processus qui affecte presque certainement votre développement de code impératif, même si vous ne le savez pas.
Craig
1
Une des choses que j'ai faites dans le passé a été de mettre une instance de développement du serveur de base de données sur des postes de travail de développeurs individuels, ou si cela n'était pas possible, il faudrait au moins des instances "dev" et "de production" des bases de données. ainsi que tous les scripts DDL et DML, ainsi que des exemples de scripts de chargement et de données, résidant dans leur propre répertoire dans l’arborescence source, et la base de données a été systématiquement construite à partir de ces scripts à l’aide du fichier MAKE. Les développeurs ont également pu utiliser nmake pour créer un seul procs stocké. S'ils ne le mettaient pas sous contrôle de source, il disparaîtrait sur eux et ils le savaient.
Craig
1
... Je ne voulais pas paraître dégoûtant dans mon commentaire précédent, avec l'expression "..., même si vous n'êtes pas au courant ...". Ce que je voulais dire, c'est que si ce type de problème se produit avec les procédures stockées, il en va probablement de même dans d'autres parties du projet. Personnellement, je n'aime pas le contrôle de source intégré dans l'EDI, en partie parce que je pense que cela rend les gens plutôt paresseux en termes de réflexion sur ce que signifie réellement pour l'équipe et le projet dans son ensemble d'apporter des modifications et de les appliquer au contrôle de source. dépôt. Ces choses ne devraient pas être "automatiques" à mon avis.
Craig
9

C'est tellement contraire à tout ce que j'ai appris.

Vous pourriez avoir besoin de sortir plus. [sourire] Sérieusement, les procédures stockées sont en baisse depuis au moins 10 ans. Pratiquement depuis que n-tier a remplacé client-serveur. Le déclin n'a été accéléré que par l'adoption de langages OO tels que Java, C #, Python, etc.

Cela ne veut pas dire que les procs stockés n'ont toujours pas leurs partisans et leurs défenseurs - mais ceci est une discussion et un débat de longue haleine. Ce n'est pas nouveau et durera probablement encore longtemps; OMI, les adversaires des procs stockés sont clairement en train de gagner.

Les procédures stockées vous permettent de réutiliser le code et de l'encapsuler (deux piliers du développement logiciel)

Très vrai. Mais, il en va de même pour une couche d’architecture décente.

sécurité (vous pouvez accorder / révoquer des autorisations sur un proc stocké)

Bien que vous puissiez le faire, peu le font en raison de limitations sérieuses. La sécurité au niveau de la base de données n'est pas assez granulaire pour prendre des décisions tenant compte du contexte. En raison des performances et des frais de gestion, il est également inhabituel d’avoir des connexions par utilisateur - vous avez donc besoin d’un certain niveau d’autorisation dans le code de votre application. Vous pouvez utiliser des connexions basées sur les rôles, mais vous devrez les créer pour de nouveaux rôles, conserver le rôle que vous exécutez, changer de connexion pour effectuer un travail "au niveau système", comme la journalisation, etc. Et finalement, si votre application est détenue - ainsi que votre connexion à la base de données.

vous protéger des attaques par injection SQL

Pas plus que de faire des requêtes paramétrées. Ce que vous devez faire quand même.

et aide également avec la rapidité (bien que le DBA ait dit qu'à partir de SQL Server 2008, même les requêtes SQL régulières soient compilées si elles sont exécutées suffisamment de fois).

Je pense que cela a commencé avec MSSQL 7 ou 2000. Il y a eu beaucoup de débats, de mesures et de fausses informations sur les performances du processus stocké par rapport au SQL inline - je regroupe tout cela sous YAGNI. Et, si vous en avez besoin, testez.

Nous développons une application complexe utilisant la méthodologie de développement logiciel Agile. Quelqu'un peut-il penser aux bonnes raisons pour lesquelles il ne souhaite pas utiliser de procs stockées?

Je ne peux pas penser à de nombreuses raisons que vous voulez à. Java / C # / tous les langages de 3ème GL sont tous beaucoup plus capables que T-SQL pour l’encapsulation, la réutilisation et la flexibilité, etc. La plupart d’entre eux sont gratuits avec un ORM semi-décent.

De plus, étant donné le conseil de "distribuer au besoin, mais pas plus" - je pense que le fardeau de la preuve incombe de nos jours aux avocats de SP. L'une des raisons les plus courantes de la lourdeur des procédures stockées réside dans le fait que T-SQL est plus simple que OO et que la boutique dispose de meilleurs développeurs T-SQL que OO. Ou que le DBA s'arrête au niveau de la couche de base de données et que les procédures stockées constituent l'interface entre dev et DBA. Ou bien, vous expédiez un produit semi-personnalisé et les procédures stockées peuvent être personnalisées par l'utilisateur. En l'absence de considérations de ce type, je pense que la gestion par défaut de tout projet de logiciel Agile sera désormais ORM.

Mark Brackett
la source
1
Il y a BEAUCOUP à gagner en performance si vous n'avez pas à transférer de gigantesques ensembles de données hors de la base de données pour effectuer des tâches simples. Mesurer et optimiser si nécessaire.
Précisément. Les procédures stockées peuvent être utilisées comme un scalpel. C'est une garantie absolue que les E / S à l'intérieur du serveur de base de données ont plus de bande passante que les E / S entre le serveur de base de données et votre niveau intermédiaire. Et vous n'écrirez pas de code de jointure de données plus rapide et plus efficace dans votre niveau intermédiaire que le moteur de base de données que les développeurs ont écrit sur le serveur de base de données. Si vous transférez 1 000 000 rangées de données vers votre niveau intermédiaire pour effectuer une jointure, ce que j'ai certainement vu, vous devez simplement être fouetté ... C'est comme les gars qui prétendent que vous devriez "écrire votre propre code de restauration." Folie.
Craig
1
Ne sous-estimez pas votre serveur de base de données. Apprenez à l'utiliser correctement.
Craig
1
FWIW, vous n'avez pas besoin d'un proc stocké pour faire une jointure côté base de données. Et si vous utilisez un curseur pour la logique procédurale, vous avez probablement déjà perdu la guerre des performances. Abandonner les procédures stockées n’est certainement pas la même chose que renoncer à SQL ou à des solutions basées sur des ensembles.
Mark Brackett
1
Totalement vrai, et en fait, je plaidais davantage pour SQL que pour plaider spécifiquement pour les sprocs. Cependant, avoir du code SQL intégré dans votre code impératif n'est pas nécessairement la clé du bonheur, non? Ce qui mène souvent au débat ORM dans son ensemble, ce qui me conduit ensuite à indiquer des comparaisons de performances entre l'accès à la base de données piloté par ORM et le simple fait d'apprendre à utiliser SQL. J'ai tous deux vu et entendu parler de systèmes dans lesquels, par exemple, les consultants Oracle recommandaient d'éviter toute charge possible sur le serveur de base de données, ce qui conduirait à un middleware lourd (et extrêmement coûteux!) Aux performances abyssales .
Craig
4

Compte tenu de tous les cas ci-dessus, je voudrais en ajouter un de plus. Le choix de la SP dépend peut-être aussi du choix des personnes.

Personnellement, je me sens frustré lorsque des personnes mettent en place une logique très complexe dans SP, et j’estime qu’un tel SP est très complexe à maintenir et à déboguer. Même dans de nombreux cas, le développeur lui-même est confronté à un problème lorsque le débogage dans le code (beaucoup de langage) est beaucoup plus facile que dans SP.

SP ne doit être utilisé que pour des opérations simples. Eh bien c'est mon choix.

Rimbik
la source
4

Je veux couvrir à la fois certains pour et contre des processus stockés. Nous les utilisons beaucoup avec LedgerSMB , et notre règle est, avec une extension très spécifique, "s'il s'agit d'une requête, faites-en un processus stocké".

Notre objectif était de faciliter la réutilisation de requêtes multilingues. Il n'y a pas de meilleure façon de le faire honnêtement.

En fin de compte la question est toujours sur les détails. Bien utilisées, les procédures stockées facilitent beaucoup les choses et mal utilisées, elles les rendent beaucoup plus difficiles.

Donc, du côté des arnaqueurs.

  1. Comme cela est traditionnellement utilisé, les procédures stockées sont fragiles. Utilisés seuls, ils créent la possibilité d'ajouter des bogues à votre code dans des endroits inattendus pour des raisons autres que le changement de syntaxe de l'appel. Utilisé seul, c'est un peu un problème. Il y a beaucoup trop de cohésion entre les couches et cela pose des problèmes.

  2. Oui, il est possible d’avoir une injection sql intra-sproc si vous faites un sql dynamique. Il est mauvais d’avoir une trop grande confiance en soi dans ce domaine et, par conséquent, il est nécessaire d’avoir une expérience significative de la sécurité dans ce domaine.

  3. Les modifications apportées aux interfaces posent quelques problèmes avec les procédures stockées pour la raison n ° 1 ci-dessus, mais cela peut devenir un très grand cauchemar si de nombreuses applications clientes sont impliquées.

Ce qui précède est assez difficile à nier. Ils se produisent. Tout le monde, pro-SP et anti-SP, a probablement eu des histoires d'horreur à ce sujet. Les problèmes ne sont pas insolubles, mais si vous n'y prêtez pas attention, vous ne pouvez pas les résoudre (dans LedgerSMB, nous utilisons un localisateur de services pour créer de manière dynamique des appels SP au moment de l'exécution, évitant ainsi totalement les problèmes ci-dessus. Bien que nous soyons PostgreSQL seulement, quelque chose de similaire pourrait être fait pour les autres bases de données).

Sur les points positifs. En supposant que vous puissiez résoudre les problèmes ci-dessus, vous obtenez:

  1. La possibilité d'une clarté accrue dans les opérations d'ensemble. Cela est particulièrement vrai si votre requête est très grande ou très flexible. Cela conduit également à une testabilité améliorée.

  2. Si un localisateur de services travaille déjà dans ce domaine, je trouve que les procédures stockées accélèrent le développement, car elles libèrent le développeur d'applications des préoccupations liées à la base de données, et inversement. Cela a quelques difficultés à bien faire, mais ce n’est pas si difficile à faire.

  3. Requête réutilisation.

Oh, et quelques choses que vous ne devriez presque jamais faire dans un SP:

  1. logique non transactionnelle. Vous avez envoyé le courrier électronique indiquant que la commande avait été expédiée, mais que la transaction avait été annulée ... ou que vous attendiez de continuer pour que le serveur de messagerie se connecte ... ou pire, vous annulez votre transaction simplement parce que vous ne parvenez pas à joindre le serveur. serveur de messagerie ....

  2. beaucoup de petites questions mal articulées, parsemées de logique procédurale ...

Chris Travers
la source
Tout à fait d’accord, pour garder les fichiers non transactionnels en dehors des procédures stockées. Dans cet exemple de courrier électronique, le message électronique doit quand même être déposé dans une file d'attente et traité de manière asynchrone. Vous parlez de vous préparer à un impact énorme sur les performances et à un comportement funky sous charge, en rendant vos transactions de base de données dépendantes de la réponse de votre serveur de messagerie? Beurk!
Craig
3

Pour qui travailles-tu?

La réponse peut dépendre de votre employeur, du cabinet de conseil ou de l'entreprise elle-même. Ce qui est préférable pour une entreprise ne l'est souvent pas pour un cabinet de conseil ou un autre fournisseur de logiciels. Par exemple, une entreprise intelligente souhaite avoir un avantage permanent sur ses concurrents. En revanche, un éditeur de logiciels souhaite pouvoir proposer la même solution à toutes les entreprises d’un secteur particulier, au moindre coût. S'ils réussissent, le client ne disposera d'aucun avantage concurrentiel net.

Dans ce cas particulier, les applications vont et viennent, mais très souvent, la base de données d’entreprise vit toujours. L'une des tâches principales d'un SGBDR consiste à empêcher les données indésirables d'entrer dans la base de données. Cela peut impliquer des procédures stockées. Si la logique est bonne et qu'il est hautement improbable qu'elle change d'année en année, pourquoi ne devrait-elle pas être conservée dans la base de données, en gardant sa cohérence interne, quelle que soit l'application écrite pour utiliser la base de données? Des années plus tard, une personne aura une question à poser à la base de données et elle sera responsable si des fichiers indésirables ont été empêchés d'entrer dans la base de données.

Cela a peut-être quelque chose à voir avec le fait que votre administrateur de base de données travaille pour un cabinet de conseil. Plus leur code est portable, plus ils peuvent être réutilisés d'un client à l'autre. Plus ils ont de logique dans leur application, plus l'entreprise est liée au fournisseur. S'ils laissent derrière eux un grand gâchis, ils seront payés pour le nettoyer ou ne le verront plus jamais. De toute façon, c'est une victoire pour eux.

entrez la description de l'image ici

Pour plus de discussions des deux côtés de la clôture, lisez la discussion sur le code d'horreur . FWIW Je penche du côté des défenseurs des SP.

utilisateur21007
la source
1
Cette réponse vise à lier la question de l’utilisation des procédures stockées à la question de savoir pour qui vous travaillez et quelles sont leurs motivations. Downvote. La réponse devrait plutôt être axée sur la nécessité de lier ou non les procédures stockées aux avantages et aux inconvénients des procédures stockées. Si la réponse portait sur l'idée que les SP empêchaient l'entrée de courrier indésirable dans la base de données, je n'aurais pas voté vers le bas. Je ne serais pas d'accord, dans l'intérêt de la divulgation, mais je n'aurais pas voté à la baisse.
Yfeldblum
Aussi, vous avez lié un article de 2004, à mon humble avis, le paysage a beaucoup changé depuis. Les OR / M sont devenus beaucoup plus banals. Ruby / Rails ActiveRecord, MS est sorti avec linq & EF, Django pour le python, etc.
Brook le
@Justice, il a cependant raison, si les meilleures pratiques de la zone stockée dépendent beaucoup de la société et du rôle qu'elle joue. Par exemple, les procs stockés vous permettent de définir des autorisations sur le proc lui-même et non directement sur la table. Si vous effectuez des travaux financiers et que vous devez envisager des contrôles internes, ils constituent la seule option viable pour protéger vos données des utilisateurs. Mais si vous créez des produits commerciaux avec plusieurs backends possibles, ils sont aussi spécifiques à une base de données. Si vous êtes un cabinet de conseil, vous devrez peut-être envisager plusieurs approches différentes, selon ce qui convient le mieux aux circonstances.
HLGEM
3
@HLGEM Je ne m'oppose à aucun des points que vous avez soulevés. Mais je m'oppose à la thèse de la réponse selon laquelle la raison principale pour laquelle l'administrateur de base de données pourrait mettre la logique dans l'application est parce qu'il est consultant et qu'il a l'intention de niquer le client. Cela lie le statut moral d'une personne à son choix d'utiliser ou non des procédures stockées. À mon avis, il existe des arguments techniques des deux côtés, et les arguments des deux côtés diffèrent d’une application à l’autre, d’une technologie à une technologie, d’une entreprise à l’autre, d’un secteur à l’autre. Et je rechercherai d’abord le mérite avant de lancer un appel.
Yfeldblum
Il a dit qu'il travaillait pour un cabinet de conseil. Garder plus de contrôle sur le code par rapport aux procédures stockées déployées sur le site du client est une raison très légitime, ce pourrait être leur "meilleure pratique". Il ne s’agit peut-être pas de "foutre le client" mais peut-être un problème de contrôle accru.
Jesse
3

Il est très difficile de changer de marque de base de données et d'utiliser les mêmes procédures stockées.

Votre équipe n’a pas non plus de DBA et personne ne veut rien avoir à faire avec SQL.

Ce n'est rien de plus qu'un concours de pisse de programmeur et de DBA.

JeffO
la source
2

OMI cela dépend. Les procédures stockées ont leur place, mais ce ne sont pas une bonne pratique, ni une chose à éviter à tout prix. Un développeur intelligent sait comment évaluer correctement une situation donnée et déterminer si une procédure stockée est la solution. Personnellement, je suis un partisan d’utiliser un ORM quelconque (même de base, tel que Linq brut en SQL) plutôt que des procédures stockées, sauf peut-être pour des rapports prédéfinis ou similaires, mais là encore, c’est vraiment au cas par cas.

Wayne Molina
la source
Les votants descendants doivent commenter.
SandRock
2

C'est toujours une source de problèmes que la logique métier soit scindée entre différentes couches, à l'aide de différents langages de programmation. Le traçage d'un bogue ou la mise en œuvre d'un changement est beaucoup plus difficile lorsque vous devez basculer entre les mondes.

Cela dit, je connais des entreprises qui réussissent très bien en intégrant toute la logique métier dans des packages PL / SQL résidant dans la base de données. Ce ne sont pas de très grandes applications, mais pas triviales non plus; dire 20K-100K LOC. (PL / SQL convient mieux à ce type de système que T-SQL, donc si vous ne connaissez que T-SQL, vous secouez probablement la tête pour ne plus croire maintenant ...)

utilisateur281377
la source
2

C'est un autre point non encore mentionné:

Les outils de génération de code et les outils de reverse engineering ne peuvent pas vraiment gérer les procédures stockées. L'outil généralement ne peut pas dire ce que le proc fait. Le proc retourne-t-il un jeu de résultats? Plusieurs résultats? Est-ce qu'il extrait ses résultats de plusieurs tables et tables temporaires? Le proc est-il juste une déclaration de mise à jour encapsulée et ne renvoie rien? Renvoie-t-il un résultat, une valeur de retour et une "sortie de console"?

Par conséquent, si vous souhaitez utiliser un outil pour créer automatiquement une couche DTO et DAO d'objet de transfert de données (comme le fait le "constructeur de services" de liferay), vous ne pouvez pas le faire facilement.

De plus, les ORM comme Hibernate ne peuvent pas vraiment fonctionner correctement lorsque la source de données est un SP. L'accès aux données est au mieux en lecture seule.

knb
la source
Il est intéressant de noter que les outils de génération de code ont apparemment beaucoup de difficulté à déterminer si une procédure stockée renvoie un jeu de résultats, alors que la procédure stockée elle-même ne présente aucun problème avec cela.
Craig
2

Programmation en solo, je ne peux pas résister à l' écriture des procédures stockées.

J'utilise principalement MySQL. Je n'ai jamais utilisé de bases de données orientées objet comme PostGreSQL, mais ce que je suis capable de faire avec les SP dans MySQL est un peu abstrait de la structure de la table. Les SP me permettent de concevoir ces actions primitives, dont les entrées et les sorties ne changeront pas , même si la base de données sous- jacente change.

Donc, j'ai une procédure appelée logIn. Lorsque vous vous connectez, vous passez toujours juste usernameet password. Le résultat renvoyé est l'entier userId.

Quand logInest une procédure stockée, je peux maintenant ajouter du travail supplémentaire à effectuer lors de la connexion, qui se produit en même temps que la connexion initiale. Je trouve une série d'instructions SQL avec logique intégrée dans une procédure stockée plus facile à écrire que environnement FETCH) -> (obtenir le résultat) -> (environnement appelant FETCH) que vous devez faire lorsque vous écrivez votre côté serveur logique.

bobobobo
la source
1

Je tiens également à souligner que les procédures stockées utilisent le temps CPU sur le serveur. Pas beaucoup, mais certains. Une partie du travail effectué dans la procédure de travail pourrait être effectuée dans l'application. Il est plus facile de redimensionner la couche d'application que la couche de données.

Christopher Mahan
la source
3
Difficile de mettre à l'échelle une base de données?
JeffO
1
C'est au moins beaucoup plus cher (à moins que vous n'utilisiez MySQL) et dans de nombreux endroits où j'ai travaillé pour obtenir une autre licence SQL Server Enterprise Edition, c'est comme si on se tirait les dents
ben f.
la mise à l'échelle de la base de données n'est pas plus difficile que la mise à l'échelle d'une couche d'application.
Brian Ogden
1

Je conviens avec Mark que la communauté s’éloigne réellement des procédures stockées depuis un certain temps déjà. Alors que bon nombre des points soulevés par l’affiche originale expliquaient pourquoi nous voudrions peut-être utiliser des PS étaient valables à un moment donné, cela fait un moment que, comme l’a dit une autre affiche, l’environnement a changé. Par exemple, je me souviens que l'un des arguments pour utiliser les SP «de retour dans la journée» était les gains de performance obtenus du fait que leurs plans d'exécution étaient «précompilés» alors que le code SQL dynamique de notre code devait être «recompilé» à chaque exécution. Ce n'est plus le cas car les principales bases de données ont été modifiées, améliorées, adaptées, etc.

Cela dit, nous utilisons des SP sur mon projet actuel. La raison en est tout simplement parce que nous construisons de nouvelles applications sur une base de données existante qui prend toujours en charge les applications héritées. Par conséquent, il est très difficile de modifier les schémas jusqu'à ce que les applications héritées soient désactivées. Nous avons délibérément décidé de concevoir nos nouvelles applications en fonction du comportement et des règles requises, et d'utiliser les SP pour établir une interface temporaire avec la base de données comme nous le souhaiterions et permettre aux SP de s'adapter au code SQL existant. . Cela indique que les SP facilitent les modifications au niveau de la base de données sans nécessiter de modification du code de l'application. Utiliser des SP comme implémentation du modèle d’adaptateur me semble tout à fait logique (surtout compte tenu de mon projet actuel),

Fwiw, nous avons l’intention de supprimer les SP lors de la mise à jour du schéma. Mais, comme pour tout ce qui concerne le développement des entreprises, nous verrons si cela se produit jamais! [sourire]

SonOfPirate
la source
0

Je voulais juste faire un aperçu concis de la façon dont je recommanderais l'utilisation de procédures stockées. Je ne pense pas que ce soit une mauvaise pratique, et comme d’autres ont dit, ils devraient être utilisés dans les situations appropriées.

Je peux voir des problèmes dans lesquels les procédures d'écriture pour différentes applications peuvent créer des confusions dans les fonctionnalités et séparer la logique métier de l'application. La base de données devient ainsi plus désorganisée et plus restrictive.

Par conséquent, j'utiliserais une procédure stockée dans les tâches relationnelles orientées données spécifiques à la base de données. En d'autres termes, s'il existe une logique utilisée pour les opérations de base de données qui est cohérente avec les données de toute application, une procédure stockée peut être utilisée pour conserver les données stockées de manière cohérente (est logique). Je pense que les bons exemples de ceci sont: la journalisation cohérente, la maintenance cohérente, le travail avec des informations sensibles, etc.

Je pense que les autres tâches consistant à manipuler les données pour répondre aux besoins de l'application qui suivent le modèle de données solide de la base de données doivent ensuite être stockées dans une autre couche contenant la logique métier. En bref, la manipulation de données spécifique à la base de données pour des raisons de cohérence pourrait utiliser des procédures stockées, la cohérence s’étendant au-delà du modèle de schéma d’intégrité de base de données.

marque
la source
-1

Les procédures stockées "pour moi" conviennent aux opérations OLAP "en lecture seule", usage rare.

Pour les règles métier, les opérations de lecture / écriture OLTP, je préfère les serveurs d’applications Java. Pour faciliter le codage et, autant que possible, soulager la charge processeur et la mémoire des serveurs maîtres de la base de données. Dans cette configuration, tous les codes des serveurs d'applications ne sont pas difficiles à réviser ni à consigner, ni à être évolutifs.

Ce qui est important pour moi, c’est qu’il est plus facile de déboguer dans la couche de gestion que de déboguer des procédures stockées.

jaizon lubaton
la source
Vous avez émis certaines hypothèses: que le PO a besoin d’OLAP (non indiqué dans la question); que la plate-forme utilisée utilise des serveurs d'applications Java (peu probable, car la balise concerne SQL Server). Vous répondez également n'apporte rien que les 22 autres réponses ne couvraient pas déjà
Adam Zuckerman
Je disais juste que si je commence un nouveau projet, j'utiliserai rarement une procédure stockée pour des opérations en lecture seule, juste un choix personnel. Je trouve plus pratique de faire la plupart des codages sur la couche de logique métier au lieu de la couche de données.
jaizon lubaton
cela ne semble rien offrir de substantiel par rapport aux points soulevés et expliqués dans les 24 réponses précédentes, ce qui ne vaut guère la peine de cogner une question de 4 ans
gnat
-2

En plus de distribuer inutilement la logique métier et de vous associer à un fournisseur de base de données spécifique, je crois également fermement à l’utilisation d’une technologie conforme à son objectif. Une base de données est simplement un magasin de données relationnel. Utilisez-le pour stocker des données, rien d'autre.

Choisissez judicieusement vos outils et vous vous épargnerez un monde de blessures à long terme.

Nico
la source
si vous voulez voter par la suite, faites-le, mais expliquez au moins pourquoi.
Nico
probablement parce que tu as tort. Un SP ne signifie pas que vous écrivez du code, mais que vous écrivez vos requêtes d'accès aux données (dans 99% des cas, je pense). De plus, le simple fait de mettre des déclencheurs et des contraintes sur le modèle de données compte comme un «code» - c'est-à-dire une logique opérationnelle, pas des données. D'où mon point que vous avez tort.
gbjbaanb
Où définissez-vous les transformations sur vos données stockées autres que dans la base de données?
Chris Travers