SQLデータベースのベストプラクティス - アーカイブテーブルの使用？

Question

私は訓練されたDBAではありませんが、いくつかのSQLタスクを実行し、この質問をしています：

SQLデータベースでは、私は同じフィールドを持つ別のテーブルを模倣し、そのデータがアーカイブとみなされたときに元の表の行を削除します。これらのテーブルが同じデータベースと同じドライブにある例を見てきたので、これはパフォーマンスを向上させるためのものです。このようなテーブルには、約1,000万行以上はありませんでした。

• 列を使用して行のステータスを指定する代わりに、これを行う理由は、in /アクティブフラグ？
• これにより、いつパフォーマンスが向上しますか？
• データを依然として照会（または現在のデータとの結合）する必要がある場合、これを正しく構成するにはどのようなパターンが最適でしょうか？
• これについて他に何がありますか？

Answer 1

私は、同じ構造の

複数のテーブルが理にかなっていることはほとんどない、頻繁にこれを言うが...。

状況フラグはもっと良いアイデアです。データを非正規化したり、冗長性を作成したりせずに、パフォーマンスを向上させる（パーティション化/索引付け）適切な方法があります。現代のrdbmsの世界では、1000万レコードがかなり小さいので、データベースの計画や誤解がないことが原因です。

Answer 2

アーカイブの概念は物理的で論理的ではありません。論理的には、アーカイブテーブルには同じエンティティが含まれていて、同じテーブルである必要があります。

物理的な懸念は実用的な傾向があります。最も重要な概念は、「データベースが大きくなっている（大きく/遅い）」ということです。レコードをアーカイブすると、次のようなことを簡単に行うことができます。

1. インデックス構造を異なる方法で最適化します。アーカイブテーブルは、作業テーブルの挿入/更新のパフォーマンスに影響を与えずに、より多くのインデックスを持つことができます。さらに、索引は全ページで再構築できますが、作業表では一般に50％のフル・バランスのページが必要です。

2. 記憶メディアを異なる方法で最適化します。容量の大きい低速または低価格のディスクドライブにアーカイブテーブルを置くことができます。

3. 異なるバックアップ方法を最適化します。作業表では、ホット・バックアップまたはログ・シッピングが必要な場合がありますが、アーカイブ表ではスナップショットを使用できます。

4. 使用している場合は、複製を別々に最適化します。アーカイブテーブルが夜間バッチで1日に1回だけ更新される場合、トランザクションレプリケーションではなくスナップショットを使用できます。

5. アクセスレベルが異なります。おそらく、アーカイブ・テーブルのセキュリティ・アクセス・レベルが異なることが必要です。

6. ロック競合。作業表が非常に熱い場合は、MIS開発者にアーカイブ表にアクセスさせて、何かを実行したときに操作を停止させる可能性が低く、ダーティな読取りセマンティクスを指定することを忘れてしまいます。

のベストプラクティスは、非正規化データとMISデータベース、データウェアハウス、またはデータマートにOLTPデータベースからデータを移動するのではなく、アーカイブ表を使用しないでしょう。しかし、一部の組織では、追加のDBシステム（安価ではない）のコストを正当化するのに問題があります。既存のDBに追加のテーブルを追加するのには、はるかに少ないハードルがあります。