緊急の質問: テーブルと 10 個のフィールドに 120 万個のデータがあり、そのうち 3 つは 99% 空です。これは適切ですか?

.
今、非常に複雑なビジネス ロジックに直面しているので、中間テーブルでそれを切り取ろうとします -
当初、この中間テーブルには 120 万個のデータがあると推定されていますが、ビジネス ニーズのために、このテーブルは実際にはユーザーごとに 1 つの統計データと、状態識別型の週次/月次/四半期統計データの 2 種類のデータを保存します。 (以下のテーブル構造を参照)
したがって、ほとんどのデータの後者のカテゴリ (3 つのフィールド) は空です。 (データベース内の他のテーブルを調べたところ、かなりの数のフィールドの値が 0 または NULL であることがわかり、この悪いアイデアを思いつきました)

大まかなテーブル構造 (厳密ではありません):
| groupId (99% 空) | lastTime(99% 空) |

知りたい:

1. この量の空のフィールドは

   効率 に影響しますか?

2. サブテーブルに加えて、

   解決策はありますか?

この種のテーブル設計作業にはバックエンド プログラムが必要ですか?無力感でいっぱい。

返信内容:

.

今、非常に複雑なビジネス ロジックに直面しているので、中間テーブルでそれを切り取ろうとします -
当初、この中間テーブルには 120 万個のデータがあると推定されていますが、ビジネス ニーズのために、このテーブルは実際には2 種類のデータを保存します。各ユーザーは、週/月/四半期の統計データ、ステータス識別タイプの 1 つの項目を持ちます。 (以下のテーブル構造を参照)
したがって、ほとんどのデータの後者のカテゴリ (3 つのフィールド) は空です。 (データベース内の他のテーブルを調べたところ、かなりの数のフィールドの値が 0 または NULL であることがわかり、この悪いアイデアを思いつきました)

大まかなテーブル構造 (厳密ではありません):

| groupId (99% 空) | lastTime(99% 空) |

知りたい

:

この量の空のフィールドは
1. 効率

   に影響しますか?

サブテーブルに加えて、
2. 解決策

   はありますか?

この種のテーブル設計作業にはバックエンド プログラムが必要ですか?無力感でいっぱい。

そのフィールドが使用されない場合は削除してください。

使用される可能性がある場合は、クエリ時に必須フィールドを指定しても大きな問題はありません。