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.

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.

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.

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.

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

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.

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?

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.

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.

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.

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.

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 ...

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.

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.

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.

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.

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 ...)

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.

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.

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.

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]

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.

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.

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.