トランザクションデータベース内のスナップショットの設計と参照データのバージョン化

Question

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

少し長いです。私と一緒に我慢してください。

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

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

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

また、ファイナンスユーザーは予算だけをスナップショットすることを決定でき、セールスマネージャーは販売目標をスナップショットできます。したがって、スナップショットは複数の粒度で利用できます。

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

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

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

スナップショットを元のデータと同じ表に保存します。したがって、提案スナップショットは、提案テーブルにライブ提案で保存されます。すべてのテーブルに出版IDという列があり、公開する必要があります。この列は、出版物のFKです。公開IDがnullの場合、そのレコードはアクティブバージョンです。

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

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

ソリューション1：毎回、オブジェクトが公開されます（提案や予算など）、XMLツリーを入力し、これをデータベースに保持します。ウェブサイトで利用できる最新バージョンのみが必要であり、古いバージョンはめったに必要ありません。これを考えると、XMLを使用しているため、大きなパフォーマンスの問題に遭遇しますか？ SQL Serverを使用します。データボリュームは、それほど大きくないということです。

ソリューション2：すべてのトランザクションテーブルには公開IDがあり、参照データには開始日と終了日があります。オブジェクトが公開されるたびに、すべてのトランザクションレコードのコピーを作成し、公開IDをそこに配置し、すべての参照データレコードをコピーして、スナップショット日付を終了日として配置します。これにより、出版プロセス以外の参照データの通常のバージョン化が可能になります。

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

Answer 1

私のアプローチは、ソリューション2を選択することです。

1. すべてのコピーをスナップショットに保存します。変更のみを保存する場合、プロセスの詳細をスナップショットして、変更から目的のスナップショットを取得する問題を自分に与えます。当初、これは問題ではありませんが、スキーマ、プログラム、プロセスが変更されるため、変更されたプロセスから希望するスナップショットを再生する方法の詳細を維持する必要があります。実行可能ですが、潜在的に脆弱です。

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

3. 同じスキーマは行われません - あなたは同じスキーマが適切ではないことを（公開ID）指摘しました。あなたが投稿するものには、読書に最適化された別のスキーマを採用する必要があることを示唆するものはありません。これが必要であることが判明したとしても、それは後の段階で組み込むことができるものであり、現在の拡張スキーマを出発点として使用します。 XMLツリーの経験はあまりありませんが、「既存のインフラストラクチャを利用できる代替品があるのに、なぜ別のテクノロジーを導入するのか」と尋ねるでしょう。このアプローチから知覚する利点は、既存のアーキテクチャからのレバレッジの利点を捨てることを保証するために非常に重要でなければなりません。同様の考慮事項は、非正規化DBにも当てはまります。そうする必要があることが示されるまで、なぜそこに行くのですか？

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

5. データウェアハウスをストレージとして使用する可能性があることについて言及しますが、ソリューションでは具体的に言及されていません。あなたが示唆するように、あなたのボリュームが低い場合、私は別のデータベースが適切であると思っていたでしょう。スナップショットのデータとユーザーの両方のボリュームが低いという印象を与えているので、データウェアハウスを使用するための一応のケースはないようです。同時に、倉庫には、このタイプの歴史的データを正確に保存するためのいくつかのメカニズムがあり、読書と分析に使用されます。

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