これは、大量のレコードを含む監査テーブルに適した設計ですか？

Question

私は個々の作品ごとに在庫データを追跡するテーブルを持っています。

UniqueID, 
ProductSKU, 
SerialNumber, 
OnHandStatus, 
Cost, 
DateTimeStamp 

何かが与えられた作品は、新しい監査レコードが作成されるに起こるたびに：これは、テーブルの簡易版（一部の非キーフィールドが除外されている）です。

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

：ABCシリアル番号555点の変更のコストは、私は新しいレコードを取得する場合

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

：たとえば、私の製品ABCがインベントリに追加される最初の時間は、私はこのようなレコードを取得します

：ABCの新しい作品が持ち込まれた場合、私はこのレコードを取得

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

：作品が販売されている場合は、私はまだ別のレコードを取得します

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

の任意の時点で、特定の製品セットの手持ち在庫値を取得する必要があります。

上記の例を使用して、01/02/2009の時点で製品ABCの在庫値を取得する場合は、固有のProduct/SerialNumberの組み合わせごとにの最新のレコードを選択する必要がありますより先にから01/03/2009のステータスで「OnHand」を選択し、コストを加算します。 （私はこの選択文がこの時点でどのように見えるかは100％確信していませんが、少し実験します）。

私の質問：これは私が記述している監査テーブルのタイプのための良い構造ですか？つまり、適切に索引付けされた場合、高速問合せに役立ちますか？ （このテーブルが何百万行になると何が起こるか想像してみてください）

履歴レコードを別のテーブルに分割し、各ProductID/SerialNumberコンボの最新のレコードを "アクティブ "テーブル？

フィードバック/提案/コメント/リンクをいただければ幸いです。

ありがとうございます！

Answer 1

あなたは、監査データとは別のライブデータのテーブルを持つことが非常に簡単です。これは非常に良いアイデアです。通常の日々の運用では、監査データを見る必要はありません。そのため、ライブデータと同じテーブルで頭痛を起こすだけです。

これを管理する最も簡単な方法は、レコードが挿入/削除/更新されるたびに自動的に監査テーブルに新しいレコードが挿入されるように、ライブテーブルにトリガーを置くことです。

編集：この上Kevin'sの考えに拡大し、私は関係なく、シリアルナンバーの、同じSKUを共有するすべてのピースが同じ価格を持っているだろうと想像するでしょうか？これが当てはまる場合、別の価格表を持つことは間違いなく良い考えです。

Answer 2

すべての値が一度に更新されるわけではありませんが、静的なすべての情報を再現するのはなぜですか？私はあなたがシリアル番号、ステータス、およびコストのために異なるテーブルを持つべきだと思います。これらの各テーブルには、製品IDと更新日時も表示されます。

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

Answer 3

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

最も簡単な実装は、本番と同じスキーマを持つ別のデータベースを作成することです。監査データベースの各テーブルに日時スタンプを追加します。本番プライマリキーと新しいdatetimeスタンプからコンポジットプライマリキーを作成します。

運用データベースでトリガを設定することにより、運用データベース内の各挿入/更新が監査データベースへの挿入を開始します。監査データベースに挿入される値は、新しく挿入された値になります。

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

また、時間の経過とともに変更を追跡するデータマートを作成することもできます。 =========

：

Answer 4

まず、定義（ない臨床DEFS、ちょうど私自身の分離・オブ・アイデア命名法）のビット（しかし、それは多くの時間と労力を要します） =

初期テーブル：あなたが追加したり取得したりする日々のテーブル。

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

==========

監査テーブルのビジネスユースにはレコードは、任意の時点ではどうだったかを伝えることができるのであれば、私はそれがあるべきでしょうね初期テーブルと同じように構成されています（一意の監査IDが追加されています）。

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

全体として、ほとんどの場合、最新のバージョンのレコードを使用する高速パフォーマンスが監査データを使用するパフォーマンスよりも重要であると私は考えます。したがって、初期テーブルと同じように監査テーブルを作成すること（プライベート・サロゲート・キーに加えて）と、初期テーブルに追加するときに同じデータを監査テーブルに挿入することをお勧めします。これにより、最初のテーブルでレコードの数が比較的静的になり、パフォーマンスは時間の経過とともに低下しません。