3

私は従業員の目標 Web アプリケーションに取り組んでいます。

リード/マネージャーは、チーム メンバーと話し合った後、チーム メンバーの目標を設定します。これは、組織が従う評価サイクルに応じて、毎年/半年ごと/四半期ごとです。

問題は、期間ベースのフィールドを追加するか、前四半期/年のデータをアーカイブするためのより良いアプローチです。ユーザーが以前の目標 (それほど頻繁ではないアクティビティ) を見たい場合、その日付に属するアーカイブを一時テーブルに復元し、従業員に表示することができます。

始めるべきポイント

アーカイブ: データベースのサイズを縮小し、データベース クエリを簡素化し、誰かが古いデータを見ようとしたときにオーバーヘッドを追加します。

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

PS: これはスペース コストではありません。私のポイントは、これは Web アプリであり、組織内のすべての従業員がピーク時に検索/更新するため、パフォーマンスに関して何らかの最適化を達成できるかどうかです。期間を削除すると、クエリがはるかに簡単になります。ありがとう

4

3 に答える 3

3

ロギング タイプのデータではなく、時間の経過とともに変化するデータについて話していると仮定すると、私の推奨するアプローチは、プライマリ テーブルのデータの「最新」バージョンのみを保持し、以前のデータを自動的にコピーすることです。データのバージョンをアーカイブ テーブルに格納します。このアーカイブ テーブルは、タイムスタンプなどのバージョン管理されたフィールドを追加して、プライマリをミラーリングします。このアーカイブは、トリガーを使用して実行できます。

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

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

于 2009-07-13T12:40:15.290 に答える
1

期間フィールドを追加することから始めて、サイズが問題になるまで待ちます。あなたが説明している種類のデータは、多くのストレージ スペースを消費するようには思えません。

手に負えないほど大きくなった場合は、後でいつでもアーカイブ アプローチを検討できますが、コーディングには、関連する期間をデータと共に単に保存するよりもはるかに時間がかかります。

于 2009-07-08T05:49:09.837 に答える
1

ユーザーが任意に過去をさかのぼることができるという要件がある場合、データにアクセスできるようにしておく必要があるように私には思えます。

これは持続可能ではありません。

その日付に属するアーカイブは、一時テーブルに復元され、従業員に表示される場合があります。

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

于 2009-07-08T06:14:53.687 に答える