MS SQLデータベースに相互に関連するストアドプロシージャの巨大なWebを文書化する：どのツールまたは形式ですか？
これが「1000ページの本を読む」よりも短い答えの質問であるといいのですが、それが本当の状況なら、私をそれに当てはめてください。
私は本物のDBAではありません。私はDBAが必要だと気づいているソフトウェア開発者ですが、私が働いている店にはDBAがいません。ただし、いくつかのコアストアドプロシージャを含むMS SQLデータベースの設計は、大きな混乱です。ストアドプロシージャは遅く、バグがあると思われますが、どのように動作することが予想されるのかさえわからないため、修正方法もわかりません。
まず最初に、すべての機能がどのように機能するかを文書化し、ユニットテストを開始して、ストアドプロシージャが実際に機能することを証明する一連のユニットテストを構築することにしました。彼らが実行するロジックは、私たちのアプリケーションの重要な部分です。つまり、それは当社の主要製品の「宝石」であり、その動作方法は完全に文書化されていません。
私は、プロのDBAが相互に呼び出すストアドプロシージャの巨大なWebを理解するために、既存の、または必要に応じて自分で作成することを期待している可能性がある特定の技術文書を探しています。
大きなストアドプロシージャを文書化するための通常の形式は何ですか？各Inパラメータの期待値の説明（つまり、「前提条件」、「事後条件」、つまりブールパラメータの場合、オンまたはオフにすると何が変わるかなど）
通常、どのように文書化しますか？ SQLコメントのみ？目的に固有の外部ツールですか？外部の「ドキュメント」？ MS SQL Management Studio以外にSQLツールはありませんが、環境の理解、文書化、およびテストを改善するツールがあるかどうか疑問に思っています。多分それが私の質問をするより良い方法です。混乱を解決するには、どのツールが必要ですか？
私たちの目標は、次のことができるようにすることです。
A.生成されたドキュメント、または環境に追加したツールを使用して、手順がどのように機能するかを理解し、ストアドプロシージャの単体テストカバレッジを作成できるようにします。
B.これらの複雑なストアドプロシージャのそれぞれを適切に呼び出す方法をクライアントアプリ開発者に示す。
C.ストアドプロシージャの単体テスト。
ドキュメンテーションについて最も重要なことは、それがあなたにとって意味があるということです。これを行うための本当に標準的な方法はありません。
プロシージャごとに1つのオブジェクトを持つVisioダイアグラムから始めて、相互に接続する多くのストアドプロシージャがある場合は、プロシージャ間のリンクを追跡できるように、プロシージャ間のリンクを追跡できるので、おそらく非常に良いスタートです。
RedGate SQL Dependency Tracker ツールが役立つ場合があります。どのデータベースオブジェクト（SP、ビュー、テーブル）が相互に依存しているかをグラフィカルに表示できます。慣れていないテーブルを使用して制約を無効にする順序を決定するときに、これを使用しました。
また、面白さのためにデータベース全体で実行しましたが、これはTMIのようでした。クレイジーな相互依存ではないDBの特定の領域に焦点を当てることができる場合、それは役に立ちます。依存関係ツリーには、さまざまなアルゴリズムを使用してそれ自体を視覚的に整理するオプションがあり、それだけでevalの価値があります。
トレース。別のオプションは、重要なストアドプロシージャの最初と最後にログ行を書き込むことです。各行には、日付、「詳細レベル」、最適な「コンテキスト」、「サブコンテキスト」、プロシージャ名を含めることができます。と行数。おそらく混乱するでしょう（Windowsイベントログを考えてください）が、一部のセクションではおそらく役立つでしょう。 SPを使用して実際にログの挿入を行う場合、追加の負荷（ymmv）なしで簡単にオン/オフを切り替えることができます。
補足として、クールな11 x 17の用紙をプリンタに取り付けたところ、ニースの小さなフォントと論理的なインデントが見つかり、複雑なデータ/ SPのフローをいくつかの疑似SQLの5ページにまとめました。私はそれを数回しか参照しなかったと確信しています。標準ではなく、統合されていないものを信頼するのは難しく、古くなる可能性があるため、他の誰もそれに近づきませんでした。文書化プロセスは、コードに慣れることを余儀なくさせました！
Paul Whiteが私を無料のツールに変えてくれました Atlantis Schema Surf Atlantis Interactiveからです。