これにアプローチする最善の方法についてのアドバイスが必要です。基本的に、データベースには、削除されたデータ用のそれらのテーブルのアーカイブバージョン（BookingやBooking_archiveなど）とともにいくつかのテーブルがあります。これらの両方のテーブルのテーブル構造は、アーカイブテーブルにDateDeletedとDeletedByの2つの追加の列があることを除いて、まったく同じです。
これらのアーカイブテーブルを削除し、DateDeleted列とDeletedBy列を実際のテーブルに追加しました。私の計画は、アーカイブされた情報をアーカイブされていない情報から分離できるように、このテーブルを分割することです。
これが最善のアプローチですか？アーカイブされたデータとアーカイブされていないデータを区別するためだけに2つのテーブルを用意するというアイデアは好きではありませんでした。
これを行うための他の提案/ポインタはありますか？
アーカイブのポイントはパフォーマンスを向上させることなので、データを別のテーブルに分割する方が間違いなく良いと思います。実際、私は別のサーバーにアーカイブデータベースを作成し、そこにアーカイブデータを保持するところまで行きます。これにより、パフォーマンスが最大に向上します。次点アーキテクチャは、正確に複製されたテーブルを持つ同じサーバー上の2番目の「アーカイブ」データベースです。
パーティショニングを使用しても、テーブルロックの問題とハードウェアの制限により速度が低下します。個別のテーブルまたはデータベースは前者を排除し、個別のサーバーまたはパーティションごとに1つのドライブが後者を解決する可能性があります。
アーカイブされた日付の保存に関しては、本番データベースでわざわざ保存することはないと思います。タイムスタンプをarchive-dbテーブルに作成することもできます。そのため、レコードを挿入すると、アーカイブされた日時が自動的にスタンプされます。
ソリューションのアプローチは以下に依存します：
上記に基づいて-さまざまなオプションは次のようになります。
アーカイブされたデータであり、メインテーブルに戻る可能性がない場合は、パーティション分割を行わないでください。アーカイブデータのライフサイクル（保持期間または有効期限）にライフサイクル管理列を追加して、アーカイブデータのライフサイクルも効果的に管理できるようにすることもできます。