6

免責事項：スタックオーバーフローとインターネットの両方でスナップショットとバージョニングのトピックについて読むことができるすべてを読みました。私の要件は、監査証跡またはデータベースレベルのスナップショットのバージョン追跡ではありません。私は1週間以上を費やして、自分で調査し、可能な選択肢について考えました。申し訳ありませんが、いくつかのリンクを見逃している可能性があります-私の問題の解決策がすでに他のスレッドで議論されている場合は、そこに私を向けてください。

少し長いです。我慢してください。

状況は次のとおりです。トランザクションデータベースにトランザクションデータのスナップショットを保存し、参照データの改訂履歴を保持するための汎用設計を作成しようとしています。

ビジネスプロセスの一環として、ユーザーはボタンを押して特定のオブジェクトを公開できます。説明のために、ユーザーは交渉が始まる前にベンダーからの提案を公開できるとしましょう。次に、交渉プロセスのさまざまな時点で、ユーザーは提案データを公開できます。提案には、予算、販売目標、およびその他の多くの項目が含まれています。プロポーザルのスナップショットを作成するときは、リンクされているすべてのエンティティのスナップショットを作成する必要があります。最後に、交渉後、契約が締結されます。この時点で、契約の完全なスナップショットを作成する必要があります。契約内のすべてのエンティティがプロポーザルに含まれているわけではありません。重複するエンティティは多数ありますが、プロポーザルと契約に関連付けられている固有のエンティティがあります。

これらの公開バージョンと最新のアクティブバージョンの両方を利用可能にしておく必要があります。公開されたバージョンは、両方のベンダーと管理チームが参照できるようにWebサイトで入手できます。公開されたすべてのバージョンがWebサイトで利用できるわけではありませんが、最後に公開された提案と最新の公開された契約は常にWebサイトで利用できます。このWebサイトも、同じデータベースから作成する必要があります。

また、財務ユーザーは予算のみのスナップショットを作成することを決定でき、営業マネージャーは販売目標のスナップショットを作成できます。そのため、スナップショットは複数の粒度で利用できます。

また、マスターデータのバージョンを追跡する必要があります。主要なマスターデータ列へのすべての変更を経時的に追跡することはビジネス要件です。たとえば、販売目標に関連付けられた地域情報があります。地域の名前は変更される可能性があるため、これらの変更を追跡する必要があります。提案時に、リージョンの名前がR1であり、スナップショットが作成されていると仮定します。次に、リージョンの名前がR2に変更され、他の2つのスナップショットが作成されます。その時点での販売目標を正しい地域名にリンクできるようにしたいのですが、必ずしも最新の地域名にリンクする必要はありません。

トランザクションDBとデータウェアハウスDBの両方があるため、モデリングにある程度の柔軟性があり、この情報の一部をトランザクションDBまたはデータウェアハウスDBのいずれかに格納することを決定できます。

これが私たちのデザインです。公開されたデータに関する基本情報（誰が公開したか、日付、理由、公開されたオブジェクトのタイプ（提案、予算、または販売目標））をキャプチャする公開テーブルがあります。

スナップショットは元のデータと同じテーブルに保存されます。したがって、プロポーザルのスナップショットは、ライブプロポーザルとともにプロポーザルテーブルに保存されます。公開する必要のあるすべてのテーブルに、公開IDという列があります。この列は、PublicationテーブルへのFKです。パブリケーションIDがnullの場合、そのレコードはアクティブなバージョンです。

投稿が非常に長いことに気づきました。したがって、シナリオの詳細をリストするのではなく、マインドマップで設計上の考慮事項をすばやく要約することを考えました。 スナップショットの設計に関する考慮事項

現在、私たちが傾倒している2つのソリューションがあります。どちらも、変更されたかどうかに関係なく、すべてのデータのスナップショットを保存します。テーブル構造をそのまま維持しながらデルタのみを維持するには、スナップショットオブジェクトの挿入/更新のたびに実行する必要がある非常に複雑なストアドプロシージャが必要になります。これには時間がかかり、ボリュームはとにかくそれほど大きくないので、私はこのルートを下りたくありません。

解決策1：オブジェクトが公開されるたびに（提案や予算など）、XMLツリーにデータを入力し、これをデータベースに保持します。最新バージョンのみがWebサイトで利用可能である必要があり、古いバージョンが必要になることはめったにありません。これを考えると、XMLを使用しているために大きなパフォーマンスの問題が発生しますか？SQLServerを使用しています。データ量はそれほど大きくありません。

解決策2：すべてのトランザクションテーブルにはパブリケーションIDがあり、参照データには開始日と終了日があります。オブジェクトが公開されるたびに、すべてのトランザクションレコードのコピーを作成し、そこに公開IDを配置し、すべての参照データレコードをコピーして、スナップショットの日付を終了日として配置します。これにより、公開プロセスの外部で参照データの通常のバージョン管理を行うことができます。

これらの2つのアプローチの欠点と、他にもっと良いシナリオがあるかどうかについて、ここで経験豊富な心からの意見が必要です。

4

1 に答える 1

1

私のアプローチは、ソリューション2を選択することです。設計上の考慮事項を次の順序で実行します。

  1. スナップショットにすべてのコピーを保存します。変更のみを保存する場合は、プロセスの詳細をスナップショットして、変更から目的のスナップショットを取得するという問題が発生します。最初はこれは問題ではありませんが、スキーマ、プログラム、およびプロセスが変更されると、それ自体が変更されたプロセスから目的のスナップショットを取得する方法の詳細を維持する必要があります。実行可能ですが、壊れやすい可能性があります。

  2. ソリューション2の説明にスケッチされていますが、図に記載されていないオプションを選択します。これは、トランザクションDBのスキーマと非常によく似たスキーマを使用していますが、スナップショットに固有の情報を含めるように拡張されています。外部キーとしてパブリケーションIDを指定し、参照データの日付を指定します。トランザクションデータに関連する日付などの追加情報が必要になる場合があります。

  3. 同じスキーマでは機能しません。同じスキーマでは不十分であると指摘しました（パブリケーションID）。投稿内容には、読み取り用に最適化された別のスキーマを採用する必要があることを示唆するものはありません。これが必要であることが判明した場合でも、現在の拡張スキーマを開始点として、後の段階で組み込むことができるものです。XMLツリーの経験はあまりありませんが、「既存のインフラストラクチャを利用できる代替手段があるのに、なぜ別のテクノロジを導入するのですか？」と質問します。このアプローチから認識できる利点は、既存のアーキテクチャからのレバレッジの利点を捨てる戦争にとって非常に重要である必要があります。非正規化されたDBにも同様の考慮事項が適用されます。そうする必要があることが実証されるまで、なぜそこに行くのですか？

  4. ここでも、バージョン管理とスナップショットを追跡するアプローチを採用します。ソリューション2では、このアプローチの主な利点があります。バージョン管理プロセスではなく、スナップショットプロセスの一部として参照データのスナップショットを追加します。（つまり、スナップショットを作成するときは、適切な参照テーブルがスナップショットの一部を形成していることを確認してください）。あなたの説明から、同じデータを利用するためにたまたま2つの異なる要件があるようです。スナップショットとバージョン管理です。それらの間にはほとんど依存関係がないように思われるので、可能な限り独立させておく必要があります-結合の欠如。

  5. ソリューションでは特に言及されていませんが、データウェアハウスをストレージとして使用する可能性について言及しています。ご提案のとおり、ボリュームが少ない場合は、別のデータベースで十分だと思います。スナップショットのデータとユーザーの両方の量が少ないという印象を与えるので、データウェアハウスを使用する一応のケースはないように思われます。同時に、ウェアハウスには、読み取りと分析に使用するために、このタイプの履歴データを正確に保存するためのいくつかのメカニズムがあります。

ここであなたの質問に直接答えていないことを残念に思います-しかし、これがあなたの述べられた状況についてのいくつかの指針と別の見解を提供することを願っています。

于 2011-04-13T12:52:52.620 に答える