4

フィットネス情報を保存しているデータベースを引き継いで、特定のテーブルを1つのテーブルのままにするか、3つのテーブルに分割するかについて議論していました。

今日、次のフィールドを持つワークアウトと呼ばれる1つのテーブルがあります

id、exercise_id、reps、weight、date、person_id

したがって、1日に3つの異なるエクササイズを2セット行った場合、その日のテーブルには6つのレコードがあります。例えば：

id、exercise_id、reps、weight、date、person_id 1、1、10、100、1 / 1
/ 2010、10 2、1、10、100、1 / 1
/ 2010、10 3、1、10、100、1
/ 1 / 2010、10 4、2、10、100、1 / 1 /
2010、10 5、2、10、100、1 / 1 / 2010、10
6、2、10、100、1
/ 1/2010、 10

したがって、複数のレコードに冗長なデータ（date、personid、exercise_id）がある場合、これを3つのテーブルに正規化する必要があります。

WorkoutSummary： -id
-
date
--person_id

WorkoutExercise： -id
-
workout_id（WorkoutSummaryへの外部キー）
-exercise_id

WorkoutSets：
--id
--workout_exercise_id（WorkoutExerciseへの外部キー）
--reps
--weight

欠点は、このリファクタリング後のクエリが遅くなることだと思います。これは、以前は結合がなかった同じクエリを実行するために3つのテーブルを結合する必要があるためです。リファクタリングの利点により、将来、重複を追加することなく、ワークアウトサマリーレベルまたはエクササイズレベルで新しいフィールドを追加できるようになります。

この議論についてのフィードバックはありますか？

4

2 に答える 2

8

正規化した後、クエリが遅くなると思い込まないでください。テーブルに適切なインデックスが付けられている場合、少数のテーブルでの結合は非常に安価です。

一方、正規化されていないテーブルに対するクエリは、簡単に非常に遅くなる可能性があります。たとえば、元のスキーマでは、ワークアウトが実行された個別の日付をクエリしようとするだけで、正規化されたバージョンよりもはるかにコストがかかります。

この時点で確実に正規化します。後でパフォーマンスの問題が発生した場合は、すでに正規化されているスキーマに加えて、データの特定の部分を選択的に非正規化することができます。しかし、おそらく、小さなデータベースではそのポイントに到達することはありません。

于 2010-04-11T16:27:53.413 に答える
2

新しいリファクタリングは良さそうです。さまざまなテーブルに適切なインデックスがあれば、パフォーマンスはそれほど影響を受けません。（インデックスはすべての外部キーで作成できます）

そうです、それは完全に正常なリファクタリングのようです。

于 2010-04-11T16:27:11.010 に答える