複数のアプリケーションで使用される大規模で複雑な SQL Server 2005 DB があります。DB オブジェクトだけでなく、特定のオブジェクトを使用するアプリケーションに対して相互参照するためのデータ ディクショナリを作成したいと考えています。
たとえば、ストアド プロシージャが 15 の異なるアプリケーションで使用されている場合、その追加データも記録したいと考えています。
効率的でスケーラブルなデータ ディクショナリを作成するために留意すべき重要な要素は何ですか?
複数のアプリケーションで使用される大規模で複雑な SQL Server 2005 DB があります。DB オブジェクトだけでなく、特定のオブジェクトを使用するアプリケーションに対して相互参照するためのデータ ディクショナリを作成したいと考えています。
たとえば、ストアド プロシージャが 15 の異なるアプリケーションで使用されている場合、その追加データも記録したいと考えています。
効率的でスケーラブルなデータ ディクショナリを作成するために留意すべき重要な要素は何ですか?
それで、私は最近、非常に大きな製品のデータ ディクショナリの作成を手伝いました。変更要求プロセスを使用して、1,000 を超えるテーブルの文書化に取り組んでいました。必要に応じて、使用したスプレッドシートの修正版をお送りします。基本的に、次のことをキャプチャしました。
また、誰が追加を要求したか、連絡先情報などの情報も取得しました。主な焦点は、ビジネスの定義と、列が使用または作成された理由を明確に特定することでした。
このソリューションにはストアド プロシージャはありませんでしたが、これらをシステムに簡単に追加できることを覚えておいてください。
バックエンドには SQL Server がありましたが、フロントエンドには Access を使用しました。これにより、すでに構築済みのスキーマを使用して、多くの作業を行わなくてもリッチなユーザー インターフェイスを構築することが非常に簡単になりました。
これが開始に役立つことを願っています。他に質問がある場合はお気軽にお問い合わせください。
私は常に、この種のメタ データを格納するために SQL Server 内で「拡張プロパティ」を使用するのが好きでした。このように、各オブジェクトの説明はオブジェクトと一緒に存在し、データベース自体にアクセスできる人なら誰でもアクセスできます。これらの拡張プロパティを読み取って、適切にフォーマットされたドキュメントに変換できるツールもあるはずです。
「スケーラブル」である限り、大量のデータを拡張プロパティとして追加することに関連する問題については知りません。または、これで問題が発生したことは一度もありません。
これらの拡張プロパティは、SQL Server Management Studio の [プロパティ] ダイアログを使用して各テーブル/プロシージャ/関数/etc に設定できます。また、'sp_addextendedproperty' も使用できます。