SQLバックエンド（Postgresql）を使用したアプリケーションの設計に取り組んでいますが、設計に関するいくつかの質問があります。つまり、DBはその場で発生するネットワークイベントを保存する役割を果たします。そのため、これらのイベントに応じた「リアルタイム」アクションにより、挿入速度とパフォーマンスが重要になります。データはいくつかのテーブルで高速のデフォルト形式にダンプされます。現在、postgresqlトリガーを使用して、このデータをレポートに使用される他のいくつかのテーブルに配置しています。
通常のイベントでは、データはそれぞれ同じ主キー（イベントID）を共有する2つの異なるテーブルに挿入されます。次に、データを移動して、Webベースのレポートインターフェイスで使用されるいくつかの異なるテーブルに再配置する必要があります。私の主な目標/懸念は、最初の挿入テーブルの負荷を軽減して、彼らが自分のことを実行できるようにすることです。レポートは二次的なものですが、すでに処理されたイベントをクエリして管理する必要があるcronジョブとは対照的に、トリガーを介してオンザフライでこれを実行するのは良いことです。レポートは、最初の挿入テーブルに触れる必要があります。パフォーマンスに関して..これは理にかなっていますか、それとも私は完全にオフですか？
データが適切なレポートテーブルに配置されたら、挿入テーブルのデータを長時間保持する必要がないため、挿入パフォーマンスのために定期的にデータを整理しておきます。このシナリオについて考えるとき、これは半一般的であると確信していますが、次の3つのオプションを考え出しました。
トリガーを使用して、最初の行の挿入時にトリガーし、レポートテーブルにデータを入力します。これが私の当初の計画でした。
トリガーを使用して挿入データを一時テーブル（同じ形式）にコピーしてから、トリガーまたはcronを使用してレポートテーブルにデータを入力します。これは単なる考えでしたが、一時テーブルへの単純なコピー操作は、上記のソリューションのトリガーのクエリのいずれかをオフロードすると思います。
最初の出力プログラムを変更して、すべてのデータを1つのテーブルにダンプし（2つにまたがる場合と比較して）、その挿入をトリガーしてレポートテーブルにデータを入力します。したがって、ソリューション1がマルチテーブルからマルチテーブルのトリガーの状況である場合、これはシングルテーブルのソースからマルチテーブルのトリガーになります。
私はこれを考えすぎていますか？私はこれを正しくしたいと思います。どんな入力でも大歓迎です！