1

個々の部品ごとに在庫データを追跡するテーブルがあります。これはテーブルの簡略化されたバージョンです (一部の非キー フィールドは除外されています)。

UniqueID,
ProductSKU, 
SerialNumber,
OnHandStatus,
Cost,
DateTimeStamp

特定のピースに何かが起こるたびに、新しい監査レコードが作成されます。たとえば、私の製品 ABC が初めて在庫に追加されたとき、次のようなレコードが得られます。

1, ABC, 555, OnHand, $500, 01/01/2009 @ 02:05:22

ABC シリアル番号 555 のコストが変更された場合、新しいレコードが取得されます。

2, ABC, 555, OnHand, $600, 01/02/2009 @ 04:25:11

作品が売れた場合、さらに別の記録が得られます。

3, ABC, 555, Sold, $600, 02/01/2009 @ 5:55:55

ABC の新しい作品が持ち込まれた場合、次の記録が得られます。

4, ABC, 888, OnHand, $600, 02/05/2009 @ 9:01:01

任意の時点での特定の製品セットの手持在庫値をできるだけ早く取得できるようにする必要があります。

上記の例を使用して、2009 年 1 月 2 日現在の製品 ABC の在庫値を取得したい場合、一意の製品/シリアル番号の組み合わせごとに、01/03/より前の最新のレコードを 1 つ選択する必要があります。 2009 を "OnHand" の状態にしてから、コストを合計します。(現時点では、この select ステートメントがどのようになるかは 100% わかりませんが、少し実験してみます)。

私の質問:これは、私が説明しているタイプの監査テーブルにとって適切な構造ですか? つまり、適切に索引付けされていれば、高速なクエリに適していますか? (このテーブルが数百万行に増えたらどうなるか想像しようとしています。)

過去のレコードを別のテーブルに分割し、「アクティブな」テーブルの ProductID/SerialNumber の組み合わせごとに最新のレコードのみを残す必要がありますか?

フィードバック/提案/コメント/リンクは大歓迎です。

ありがとう！

4

4 に答える 4

1

すべての値が一度に更新されるわけではありません。静的な情報をすべて再現するのはなぜですか? シリアル番号、ステータス、およびコストに対して別のテーブルを用意する必要があると思います。これらの各テーブルには、製品 ID と更新日も含まれます。

このようにして、製品のどの部分が変更されたかを簡単に知ることもできます. 以前は、商品のすべてのフィールドを、最初のフィールドの直前に保存された商品のすべてのフィールドと比較していました。

于 2009-04-03T02:44:59.727 に答える
0

監査データを分離する必要があります。現在のデータを監査データと一緒に保持すると、時間の経過とともにパフォーマンスに影響を与えます。

最も簡単な実装は、本番環境と同じスキーマを持つ別のデータベースを作成することです。監査データベースの各テーブルに日時スタンプを追加します。本番の主キーと新しい日時スタンプから複合主キーを作成します。

本番データベースでトリガーをセットアップして、本番データベースでの各挿入/更新が監査データベースへの挿入を開始するようにします。監査データベースに挿入される値は、新しく挿入された値になります。

監査データベースは、監査レポートの目的でのみ使用してください。

または、時間の経過に伴う変更の追跡を担当するデータマートの作成を検討することもできます。（ただし、時間と手間がかかります）

于 2009-06-08T14:47:07.243 に答える
0

まず、少し定義します (臨床的な定義ではなく、私自身のアイデアの分離命名法です):

==========

初期テーブル: 追加および取得する日次テーブル。

監査テーブル: 関連する初期テーブル内の任意のレコードの複数のバージョンを保持するテーブル。

==========

監査テーブルのビジネス用途が、ある時点でレコードがどのように見えるかを知ることができるようにすることである場合、最初のテーブルと同じように構築する必要があると思います (さらに、一意の監査 ID を追加します)。

任意の時点でのフィールド値 (レコード全体ではなく) を知ることがより重要な場合は、より簡略化された table-field-value-date アプローチを試してください。このアプローチでレコード全体を再構築するには、より多くの作業が必要になることに注意してください。したがって、レコード全体の取得が必要になった場合は忘れてください。

全体として、ほとんどの場合、レコードの最新バージョンを使用した高速なパフォーマンスは、監査データを使用したパフォーマンスよりも重要であると思います。したがって、最初のテーブルと同じように監査テーブルを作成し (さらに自動番号付けされた代理キー)、最初のテーブルに追加されたときに同じデータの監査テーブルへの挿入をトリガーすることをお勧めします。これにより、最初のテーブルのレコード数が比較的静的に保たれ、時間の経過とともにパフォーマンスが低下することはありません。

于 2009-07-14T19:38:27.877 に答える