Motifs pour les procédures stockées?

Question

Existe-t-il des modèles pour écrire des procs stockés? comme:

1. Doit-on écrire 1 Sp pour mise à jour, 1 pour insertion et 1 pour sélectionner pour chaque table.
2. Quand est-ce bon de créer des vues.
3. Comment gérer les règles métier dans SP?
4. Comment réduire la duplication de code etc etc ..

Tout bon article ou un livre à lire au sujet de ces motifs ...

grâce

Answer 1

En règle générale, procs stockés suivent un CRUD (http://en.wikipedia.org/wiki/Create,_read,_update_and_delete) modèle, mais ils ne doivent pas être limités à cela.

1) Vous souhaitez probablement combiner la mise à jour et l'insertion. Si la clé primaire est remplie, c'est une mise à jour, sinon c'est un insert. Pour les GUID et autres clés générées par le client, vous mettez d'abord à jour, et si le rowcount est égal à zéro, vous devez effectuer une insertion. Le processus d'insertion/mise à jour renvoie généralement une clé primaire.

Vous allez avoir besoin d'un proc get_by_id ainsi que d'un certain nombre de get_by_non-unique-criteria, qui renvoient n'importe quel nombre de lignes. L'idée est de s'assurer que les colonnes du jeu de résultats sont identiques dans tous les processus get/list.

La cible de ces procédures n'est pas nécessairement une table, ou même une vue, mais plutôt une entité logique, vous devrez donc effectuer plusieurs jointures, à la fois pour les relations et les recherches. Cela peut aider à retourner plusieurs ensembles de résultats.

2) Les vues sont pratiques, mais pas particulièrement pertinentes pour cela. Parfois, ils aident à la réutilisation, mais pas toujours.

3) Tout dépend des règles métier. Vous pouvez certainement empêcher certains types de corruption de données au niveau de proc stocké, mais il y a des limites à ce qu'il peut ou devrait savoir. Cela dit, il existe des cas spéciaux où vous pourriez vouloir mettre plus de logique dans le proc, comme la connexion.

4) Vous ne pouvez pas toujours le faire, mais vous pouvez parfois prendre en compte le code commun dans les procs d'étapes de niveau inférieur que l'utilisateur n'appelle pas.

J'espère que c'est un début.