データベース内のデータを複製するのは良いアプローチですか？
traceroutes（他のデータの中でも）を保存する必要があるプログラムがあります。
これは、ビジネスシナリオを表す図です。
現在の私のユースケースは、次のテーブル（対応する列）を使用してtraceroutesを格納することです。
パケット
packet_id
source_ip
destination_ip
packet_length
traceroute
traceroute_id
packet_id
timestamp
path_id
パス
path_id
traceroute_id
timestamp
ip
ip_id
ip_address
path_ip
path_id
ip_id
order_index
これにより、JOINsを取り戻すためにいくつかのtracerouteを作成する必要が生じますが、traceroutesの一部を他のニーズのクエリに使用できるようになります。
tracerouteをip_addressesのjson文字列として格納する2番目のpathテーブルを作成することを検討しています。これにより、最小限のtraceroutesで完全なJOINsを回復できますが、他のクエリに使用される個々のホップ（ip_addresses）は保持されます。
私の質問は：
- この複製されたデータを持つことは意味がありますか？
- これに対するより良いアプローチはありますか？
コメントへの回答：
1つのメソッドからtracerouteデータを追加し、同時にテーブルにデータを入力します。
複製されたテーブル（おそらくtraceroute2？と呼ばれる）は検索に使用されるだけで、データが編集または更新されることはありません。
私はデータ検索の速度に最も興味があるので、これを検討しています。私はいくつかのベンチマーク（原油のようなもの）を行いました、そして私は検索で2-6倍の速度の改善を得ることができます。
私は特定の理由でJOINsを防ぎたくありません、ただこれだけ多くを避けたいです。この操作では、tracerouteの個々のホップは必要ないため、追加するときにホップを分割してから、再度つなぎ合わせても何が得られるかわかりません。
非正規化と特定の種類のデータ重複は、プロセスを高速化するための便利な方法です。例としては、キャッシング、データウェアハウジング、マテリアライズドビューがあります。
一方、複製されたデータは読み取り専用スナップショット（つまり、実際のデータのポイントインタイムコピー）として信頼されます。または、システムは一貫性を保証できます（キャッシュの場合のように）。この方法に頼っても安全です。 。
JSONの質問について...実行するSELECTsを見てください。それらのいずれかが検索（WHERE）またはソート（ORDER BY）特定のフィールドで、おそらくINDEXを使用して列として公開します。それ以外の場合は、JSON列にスローすることを検討してください。
極端な場合、すべての情報が（id、src_ip、dst_ip、timestamp、json）を含む単一のテーブルに含まれる可能性があります。
さらに極端な場合... json列の代わりに、tracerouteの生の出力を含むテキスト列を作成することもできます。つまり、元の出力をエコーするだけの場合、なぜそれを解凍して再梱包するのでしょうか。