トランザクションおよびレポート データベースに関する投稿を読みました。レポート（履歴）目的とトランザクションに使用される単一のテーブルがあります。たとえば
、orderid、ordername、orderdesc、datereceived、dateupdated、confirmOrderフィールドを持つ注文
このテーブルを neworder と orderhistory に分割するのは良い考えですか? 新しい ordertable は、当日のトランザクションを記録します (その日に受け取った注文のアクティビティをミリ秒ごとに選択、挿入、更新します。後で、このテーブルを注文履歴とマージします)。
これは推奨されるアプローチですか。これにより、データベースの負荷と処理時間が最小限に抑えられると思いますか?
PostgreSQLは、論理的に1つの大きなテーブルを小さな物理的な部分に分割できる基本的なテーブルパーティショニングをサポートしています。詳細はこちらをご覧ください。
2 番目の質問に答えるには: いいえ。ある場所から別の場所にデータを移動することは、レポートにトランザクション テーブルを使用した場合には発生しない余分な負荷です。しかし、この決定を下す前に、いくつか質問する必要があります。
そして、ここでレポート テーブルの出番です。私が見てきたアプローチでは、通常、単一のテーブルとして実装するか、データベース全体として実装するかにかかわらず、"データ ウェアハウス" を用意する必要があります。このウェアハウスは、スケジュールに従ってトランザクション テーブルからのデータで満たされ、その後、レポートの生成がトリガーされます。これはあなたが提案しているアプローチのようで、完全に有効なものです。最終的に、答えなければならない 1 つの質問は、いつサーバーに負荷を処理させたいかということです。これがピーク時以外のスケジュールで実行できる場合は、それを選択してください。いつでも実行する必要がある場合は、単一テーブルのアプローチを維持することをお勧めします。
もちろん、両方できないということはありません。小規模なオンデマンド レポートがトランザクション テーブルで実行され、履歴データのスケジュールされたウェアハウスが作成され、その履歴データに対して長時間レポートが実行されるシステムをいくつか見てきました。実際には、データをどの程度リアルタイムにしたいかだけの問題です。