Réutilisation de procédures stockées SQL sur plusieurs applications

Question

Je suis curieux de savoir comment les gens utilisent les procédures stockées dans une base de données à laquelle de nombreuses applications ont accès. Plus particulièrement, avez-vous tendance à conserver différents ensembles de procédures stockées pour chaque application, essayez-vous d'utiliser un ensemble partagé ou effectuez-vous un mélange?

D'une part, la réutilisation des SP permet moins de modifications en cas de changement de modèle ou de quelque chose de similaire et idéalement moins de maintenance. D'autre part, si les besoins des applications divergent, les modifications apportées à une procédure stockée pour une application peuvent endommager d'autres applications. Je dois noter que dans notre environnement, chaque application a sa propre équipe de développement, avec une communication médiocre entre elles. L’équipe de données dispose d’une meilleure communication et est principalement chargée de l’écriture de la procédure stockée.

Merci!

Answer 1

Tout dépend de votre stratégie d'abstraction. Les procédures stockées sont-elles traitées comme un point d’abstraction distinct ou comme une simple partie de l’application qui les appelle?

La réponse à cette question vous indiquera comment les gérer. S'ils sont une abstraction discrète, ils peuvent être partagés, comme si vous aviez besoin de nouvelles fonctionnalités, vous ajouteriez de nouvelles procédures. S'ils font partie de l'application qui les appelle, ils ne doivent pas être partagés.

Answer 2

Les procédures stockées doivent être créées en fonction des données que vous souhaitez renvoyer, et non de l'application à l'origine de la demande. Si vous avez une procédure stockée qui est GetAllItems, elle doit renvoyer tous les éléments de la base de données. Si l'une des applications souhaite obtenir tous les éléments par catégorie, créez GetAllItemsByCategory. Il n'y a aucune raison pour que les règles métier d'une procédure stockée changent en fonction de l'application qui demande les données.

Answer 3

D'après mon expérience, le partage des SP par plusieurs applications est une cause de douleur. En fait, je dirais qu’avoir une base de données à laquelle on accède directement par plusieurs applications n’est pas la meilleure architecture à long terme.

Le modèle que je recommande et que j'ai mis en place est qu'une seule application devrait "posséder". chaque base de données et fournit des API (services, etc.) permettant à d’autres applications d’accéder aux données et de les modifier.

Cela présente plusieurs avantages:

1. L’application propriétaire peut appliquer n’importe quelle logique métier, journalisation, etc. pour s’assurer de sa stabilité
2. Si le schéma est modifié, toutes les interfaces sont connues et peuvent être testées pour s'assurer que les applications externes continueront de fonctionner

Answer 4

Les procédures stockées doivent exposer les règles métier qui ne changent pas en fonction de l'application qui les utilise. Cela permet aux règles d'être stockées et mises à jour une fois au lieu de chaque endroit où elles sont utilisées, ce qui est un cauchemar.

Answer 5

Pensez-y de cette façon: vos procédures stockées concernent les données qu’elles contiennent et ne doivent pas connaître les applications situées au-dessus d’elles. Il est possible qu'une application ait besoin de lire ou de mettre à jour des données de la même manière qu'une autre ne le fait pas, et qu'une utilisera donc des fournisseurs de services que l'autre ne le ferait pas.

S'il s'agissait de mon application / base de données / etc, et que les modifications apportées à un SP pour améliorer une application en cassaient une autre, je considérerais cette preuve d'un problème de conception plus profond.

Answer 6

Je pense que la dernière partie de votre question s'est posée d'elle-même.

Avec une communication déjà médiocre, le partage des procédures entre les équipes de développement ne ferait qu’ajouter aux points de défaillance potentiels et pourrait causer des difficultés à l’une ou l’autre des équipes.

Si je fais partie de la même équipe travaillant sur plusieurs projets, nous gagnerons du temps et partagerons les procédures, mais généralement, j’ai constaté qu’un peu de duplication (quelques procédures ici et là) permettait d’éviter les changements catastrophiques / duplications nécessaires ultérieurement lorsque les applications commencent à diverger.

LordScarlet signale également un élément clé: s'il est générique sans partage de logique métier, il ne devrait pas être un problème.

Answer 7

Chaque fois que nous avions des procédures stockées communes à plusieurs applications, nous créions une base de données uniquement pour ces procédures (vues, tables et tables, etc.). Cette base de données (nous avons nommé "base") aurait alors un développeur (ou une équipe) responsable (maintenance et tests).

Si une équipe différente avait besoin de nouvelles fonctionnalités, elle pourrait l'écrire et le développeur de base l'implémenterait dans la base de données ou suggérerait une méthode plus simple.

Answer 8

Nous essayons d'utiliser un seul processus stocké partagé partagé dans la mesure du possible, mais nous avons également rencontré la situation que vous décrivez. Nous l'avons traité en ajoutant un préfixe d'application aux processus stockés (ApplicationName_StoredProcName).

Souvent, ces processus stockés appellent le "centralisé" ou le "maître". processus stocké, mais cette méthode laisse place à des modifications spécifiques à l'application plus tard.

Answer 9

Je ne pense pas que le partage de Sprocs entre plusieurs applications ait du sens.

Je peux voir le cas du partage d'une base de données dans des applications connexes, mais je suppose que ces applications sont en grande partie séparées, car elles traitent les données de manière très différente les unes des autres.

L'utilisation de la même architecture peut fonctionner avec plusieurs applications, mais imaginons d'essayer d'utiliser la même couche de logique métier dans plusieurs applications. "Mais attendez!" vous dites: "C'est idiot ... si j'utilise le même BLL, pourquoi devrais-je avoir une application distincte? Ils font la même chose! & Quot;

CQFD

Answer 10

Idéalement, utilisez un proc et non plusieurs versions. Si vous avez besoin de versions par client, examinez l’idée d’une base de données par client plutôt que d’une base pour tous les clients. Cela permet également une mise en scène intéressante de la base de données sur différents serveurs (allouez les serveurs les plus gros / les plus lourds à des serveurs plus gros, alors que les plus petits peuvent partager du matériel).

Answer 11

Si vous recherchez la possibilité de partager le code SQL, essayez de créer une bibliothèque de fonctions abstraites. De cette façon, vous pouvez réutiliser du code générique et garder la logique métier distincte pour chaque application. La même chose pourrait être faite avec les vues - elles pourraient être maintenues assez génériques et utiles pour de nombreuses applications.

Vous découvrirez probablement qu'il n'y a pas beaucoup d'utilisations des procédures stockées courantes au fur et à mesure.

Cela dit, nous avons déjà mis en œuvre un projet utilisant une base de données héritée très mal conçue. Nous avons mis en place un ensemble de procédures stockées facilitant la récupération d’informations. Lorsque d'autres personnes appartenant à d'autres équipes ont souhaité utiliser les mêmes informations, nous avons restructuré nos procédures stockées pour les rendre plus génériques, ajouté une couche supplémentaire de commentaires et de documentation et permis à d'autres personnes d'utiliser nos procédures. Cette solution a plutôt bien fonctionné.

Answer 12

De nombreuses procédures stockées sont indépendantes de l'application, mais certaines d'entre elles sont dépendantes de l'application. Par exemple, les procédures stockées CRUD (Créer, Sélectionner, Mettre à jour, Supprimer) peuvent concerner plusieurs applications. En particulier, vous pouvez introduire une logique d'audit (parfois effectuée dans des déclencheurs, mais il y a une limite à la complexité avec laquelle vous pouvez obtenir des déclencheurs). Si vous avez un type d'architecture standard dans votre magasin de logiciels, le niveau intermédiaire peut nécessiter une procédure stockée pour créer / sélectionner / mettre à jour / supprimer de la base de données quelle que soit l'application, auquel cas la procédure est partagée.

Dans le même temps, il peut exister des moyens utiles d’afficher les données, par exemple GetProductsSoldBySalesPerson, etc., qui sont également indépendants de l’application. Vous pouvez avoir un grand nombre de tables de recherche pour certains champs tels que département, adresse, etc. Il peut donc exister une procédure permettant de renvoyer une vue de la table avec tous les champs de texte. Par exemple, au lieu de SalesPersonID, SaleDate, CustomerID, DepartmentID, CustomerAddressID, la procédure retourne une vue SalesPersonName, SaleDate, CustomerName, DepartmentName, CustomerAddress. Cela pourrait également être utilisé dans toutes les applications. Un système de relation client souhaiterait un nom / adresse de client / autres attributs, comme un système de facturation. Ainsi, quelque chose qui aurait fait toutes les jointures et obtenu toutes les informations sur le client en une seule requête serait probablement utilisé dans toutes les applications. Certes, la création de manières de visualiser les données est le domaine d'une vue, mais souvent les gens utilisaient des procédures stockées pour le faire.

Donc, en gros, lors de la suppression de votre table, vous devez supprimer de 3 ou 4 autres tables pour garantir l’intégrité des données. la logique est-elle trop compliquée pour un déclencheur? Ensuite, une procédure stockée utilisée par toutes les applications pour effectuer des suppressions peut être importante. La même chose vaut pour les choses qui doivent être faites sur la création. Si des jointures communes sont toujours effectuées, il peut être judicieux de disposer d'une procédure stockée pour effectuer toutes les jointures. Ensuite, si vous modifiez les tables ultérieurement, vous pouvez conserver la même procédure et modifier la logique.

Answer 13

Le concept de partage d'un schéma de données entre plusieurs applications est complexe. Invariablement, votre schéma est compromis pour des raisons de performances: dénormalisation, quels index créer. Si vous pouvez réduire de moitié la taille d'une ligne, vous pouvez doubler le nombre de lignes par page et probablement réduire de moitié le temps nécessaire pour numériser le tableau. Toutefois, si vous n'incluez que des fonctionnalités "communes" dans la table principale et conservez des données intéressant uniquement des applications spécifiques sur des tables différentes (mais liées), vous devez vous joindre partout pour revenir à l'idée de "table unique".

Plus d'index prenant en charge différentes applications, le temps d'insertion, de mise à jour et de suppression des données de chaque table sera de plus en plus long.

Le serveur de base de données deviendra souvent aussi un goulot d'étranglement, car les bases de données ne peuvent pas être équilibrées. Vous pouvez partitionner vos données sur plusieurs serveurs, mais cela devient également très compliqué.

Enfin, le degré de coordination requis est généralement énorme. Il ne fait aucun doute que des luttes opposent différents départements pour déterminer les besoins prioritaires, et que les nouveaux développements vont s'enliser.

En général, le modèle "silo de données isolées par application" fonctionne mieux. Presque tout ce que nous faisons - je travaille pour une entreprise de logiciels sous contrat - repose sur l'importation de données et l'exportation de données vers d'autres systèmes, avec les propres bases de données de nos applications.

Cela pourrait être plus facile dans les systèmes d’entrepôt de données / d’aide à la décision; Je travaille généralement sur des systèmes OLTP où la performance des transactions est primordiale.