2009-07-08 12 views
3

私は従業員目標ウェブアプリケーションを作成しています。データベースアーカイブと時間枠ベースのテーブル/フィールド

リード/マネージャーは、チームメンバーの目標を、チームメンバーと議論した後に設定します。これは、組織が従う審査サイクルに応じて、年1回、半年毎、または四半期ごとに行われます。

ここで、期間ベースのフィールドを追加したり、前四半期/年のデータをアーカイブする方が良い方法です。ユーザーが過去の目標(あまり頻繁ではない活動)を見たい場合、その日付に属するアーカイブを一時テーブルにリストアして従業員に表示することができます。

アーカイブを開始する

ポイント:DBのサイズを縮小し、より単純なDBクエリの結果は、誰かが古いデータを参照しようとしたオーバーヘッドが追加されます。

時間ベースのフィールド/テーブル:クエリの1つ以上の余分な結合。以前のデータは現在のデータと同様に扱われるため、古いデータを取得する際のオーバーヘッドはありません。

PS:これはスペースコストではなく、パフォーマンス面で最適化を達成できるかどうかです。これはWebアプリであり、ピーク時にはすべての従業員が探しています。期間を削除すると、クエリがより簡単になります。 ありがとう

答えて

1

時間枠の追加を開始し、サイズが問題になるまで待つことにしました。あなたが記述しているデータの種類は、たくさんのストレージスペースを消費するようには聞こえません。

制御不能に成長すると、後でアーカイブアプローチを見ることができますが、データに関連する期間を保存するよりもはるかに長い時間がかかります。

+0

時間フィールドを提供しない利点は、挿入/更新/削除に関連するクエリがはるかに簡単になることです。だから私たちは、パフォーマンスとスケーラビリティを向上させることができます:) –

1

ユーザーが過去に任意に遠くまで見ることができるという要件がある場合は、実際にデータにアクセスできるようにする必要があります。

これは単に、持続可能ではありません。その日に属し

アーカイブには、いくつかの一時テーブルに復元され、従業員に示すことができます。

この目的のために、「非常に古い」データを別のテーブルに移動することをお勧めします。この時点ではディスク容量は非常に安いので、そのデータを保持することは、任意の時間に戻ってアーカイブを復元できるシステムを実装するほど高価ではありません。

+0

これはスペースコストではない、私のポイントは、これはWebアプリケーションとピーク時に組織のすべての従業員が探しているので、パフォーマンスの面でいくつかの最適化を達成することができます/更新する。 期間を削除すると、より簡単に私のクエリを作成できます:) –

3

ロギングタイプのデータではなく、時間の経過とともに変化するデータについて言えば、私の優先的なアプローチは、プライマリテーブルにデータの「最新の」バージョンのみを保持し、以前のバージョンのデータをアーカイブテーブルに自動的にコピーします。このアーカイブテーブルは、タイムスタンプなどのバージョン管理されたフィールドを追加してプライマリを反映します。このアーカイブはトリガで行うことができます。

このアプローチで見られる主なメリットは、データベース設計を損なわないことです。特に、バージョンフィールドを組み込んだ複合キーの使用については心配する必要はありません(キーがデータベースで許可されていない場合もあるため、実際には時間ベースのフィールドを使用します)。

古いデータを参照する必要がある場合は、アーカイブテーブルに対してselectを実行し、クエリにバージョン制約を追加できます。

+0

ええ、それは私の指摘でした。ちょうど別の意見を持っていたかった。ありがとう!! –

関連する問題