テーブル構造設計の問題

テーブル構造の設計、方法がわかりません、質問してください:

以下の 6 種類のテーブルを含むモジュールがあり、それらには共通して 5 ～ 6 つのフィールドがあります。 (各テーブルには 3,000 万を超えるデータがあります)

1. 新しいマスターテーブルを作成し、これらの 5 つのフィールドを分離し、ログタイプ ID を追加して 6 つのテーブル (第 3 正規形) を操作し、結合クエリを実行します。

リーリー

2. 6つの独立したテーブル

リーリー

どの方法が良いでしょうか?または他の提案はありますか?

ありがとう！

返信内容:

テーブル構造の設計、方法がわかりません、質問してください:

以下の 6 種類のテーブルを含むモジュールがあり、それらには共通して 5 ～ 6 つのフィールドがあります。 (各テーブルには 3,000 万を超えるデータがあります)

1. 新しいマスターテーブルを作成し、これらの 5 つのフィールドを分離し、ログタイプ ID を追加して 6 つのテーブル (第 3 正規形) を操作し、結合クエリを実行します。

リーリー

2. 6つの独立したテーブル

リーリー

どの方法が良いでしょうか?または他の提案はありますか?

ありがとう！

数量が多い場合
テーブルに構築すると同時に、読み込み時にesを読み込み
演算テーブルを更新し、更新されたデータをesに同期

します。

質問があまり明確ではありません。

1. 6 つのテーブル間の関係は何ですか? 共通フィールドの統計更新には一度に 6 つのテーブルを操作する必要があるのはなぜですか?

2. 今はどのように見えるのか、パフォーマンスはどうなるのか、そしてどのような種類のクエリと更新ステートメントがあるのか​​。

実際、データが 3,000 万に達したら、テーブルに分割することを検討できます。

データ量が多すぎる場合、テーブルに分割するのは避けられないため、定期的な取得の必要性を考慮する必要がある場合は、分割方法を使用することを検討できます。分割テーブルを保存するための構造。統計を高速化できます。比較的検索回数が少ない他のメソッドは、数回しか検索できません。

データ量が数千万単位であるという事実を考慮すると、データベースの負荷を軽減し、クエリ統計を高速化するために、一時的な統計テーブルを定期的に生成することを検討できます。

データ通信料金はどのようなシナリオですか?ビジネス統計を行う場合、問題を解決するために多数のテーブルに対してデカルト積を実行する必要がない場合があります。