Documenter un gigantesque réseau de procédures stockées interdépendantes dans une base de données MS SQL: quel outil ou format?

J'espère que c'est une question avec une réponse plus courte que "Lire un livre de 1000 pages", mais alors, si c'est la vraie situation, alors frappez-moi.

Je ne suis pas un vrai DBA, je suis un développeur de logiciels qui réalise que nous avons besoin d'un DBA, et pourtant la boutique dans laquelle je travaille n'a aucun DBA. Cependant, notre conception de base de données MS SQL, comprenant plusieurs procédures stockées de base, est un gâchis géant. Les procédures stockées sont lentes, nous soupçonnons qu'ils ont des bogues, mais nous ne savons même pas comment ils devraient fonctionner, nous ne savons donc pas comment les corriger.

Pour commencer, j'ai décidé de documenter comment tout cela devrait fonctionner, puis nous commencerons les tests unitaires et créerons un ensemble de tests unitaires qui aideront à prouver que les procédures stockées fonctionnent réellement. La logique qu'ils effectuent est un élément clé de notre application, vous pourriez dire, c'est les «joyaux de la couronne» du produit principal de notre entreprise, et la façon dont cela fonctionne est complètement non documentée.

Je suis à la recherche de la documentation technique spécifique qu'un DBA professionnel pourrait s'attendre à avoir existante, ou pourrait s'auto-écrire, si nécessaire, pour comprendre un gigantesque réseau de procédures stockées qui s'appellent.

1. Quel est le format habituel pour documenter une grande procédure stockée? Description des valeurs attendues pour chaque paramètre In (c.-à-d. "Préconditions", "postconditions", c.-à-d., Pour les paramètres booléens, qu'est-ce qui change lorsque vous l'activez ou le désactivez, etc.?)

2. Comment le documente-t-on habituellement? Commentaires SQL uniquement? Outillage externe spécifique à l'objectif? "Documentation" externe? Nous n'avons pas d'outils SQL, à part MS SQL Management studio, mais nous nous demandons s'il existe un outil qui permettrait de mieux comprendre, documenter et tester notre environnement. C'est peut-être une meilleure façon de poser ma question; De quel outil ai-je besoin pour résoudre notre désordre?

Notre objectif est de pouvoir:

A. Utilisez la documentation que nous générons, ou tout autre outil que nous ajoutons à notre environnement, pour aider à comprendre comment les procédures sont censées fonctionner, afin que nous puissions ensuite créer une couverture de test unitaire pour les procédures stockées.

B. Montrez aux développeurs d'applications clientes comment appeler correctement chacune de ces procédures stockées complexes.

C. Test unitaire de nos procédures stockées.

La chose la plus importante à propos de la documentation est qu'elle a du sens pour vous. Il n'y a pas de moyen vraiment standard de procéder.

Si vous avez beaucoup de procédures stockées qui se connectent toutes les unes aux autres en commençant par un diagramme Visio avec un objet pour chaque procédure, alors les liens entre eux afin que vous puissiez suivre comment les choses vont d'une procédure à l'autre est probablement un très bon début.

L' outil RedGate SQL Dependency Tracker peut être utile. Il peut vous montrer graphiquement quels objets de base de données (SP / vues / tables) dépendent les uns des autres. Je l'ai utilisé en travaillant avec certaines tables que je ne connaissais pas pour déterminer l'ordre dans lequel désactiver les contraintes.

Je l'ai également exécuté sur toute la base de données juste pour le plaisir et c'était bien TMI. Si vous pouvez le concentrer sur des zones spécifiques de la base de données qui ne sont pas interdépendantes, cela peut être utile. L'arbre des dépendances a des options pour s'organiser visuellement en utilisant différents algorithmes et cela seul vaut un eval.

Tracé. Une autre option consiste à écrire des lignes de journal au début et à la fin des procédures stockées critiques. Chaque ligne peut inclure une date, un "niveau de détail", un "contexte", un "sous-contexte", un nom de proc. et rowcounts. Ce sera probablement un gâchis (pensez au journal des événements Windows) mais peut-être utile dans certaines sections. Si un SP est utilisé pour effectuer l'insertion de journal et qu'il peut être activé / désactivé facilement sans beaucoup de charge supplémentaire (ymmv).

Note latérale, j'ai une fois chargé l'imprimante avec du papier cool 11 x 17, trouvé une jolie petite police et une indentation logique pour résumer un flux complexe de données / SP en ~ 5 pages de pseudo-SQL. Je suis presque sûr de ne l'avoir mentionné que quelques fois et personne d'autre n'a osé s'en approcher car il n'était pas standard et il était difficile de faire confiance à quelque chose de non intégré et pouvait devenir obsolète. Le processus de documentation a cependant forcé une familiarité avec le code!

Paul White m'a transformé en l'outil gratuit Atlantis Schema Surf d'Atlantis Interactive, qui peut vous être utile.