si cette table de base de données être normalisée?

Question

j'ai pris sur une base de données qui stocke les informations de remise en forme et nous avions un débat sur une certaine table et si elle doit rester comme une table ou se décomposer en trois tableaux.

Aujourd'hui, il y a une table appelée: Entraînements qui a les champs suivants

id, exercise_id, reps, poids, date, person_id

Donc, si je l'ai fait 2 séries de 3 exercices différents sur un jour, j'aurait 6 enregistrements dans cette table pour ce jour-là. par exemple:

id, exercise_id, reps, poids, 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, 01.01.2010, 10

La question est, étant donné qu'il ya des données redondantes (date, personid, exercise_id) dans plusieurs enregistrements, doit-il être normalisé à trois tables

WorkoutSummary :
 - id
 - Date
 - person_id

WorkoutExercise :
 - id
 - workout_id (clé étrangère dans WorkoutSummary)
 - exercise_id

WorkoutSets :
 - id
 - workout_exercise_id (clé étrangère dans WorkoutExercise)
 - représentants
 - poids

Je suppose que l'inconvénient est que les requêtes seraient plus lentes après refactoring que maintenant nous devons unir nos 3 tables pour faire la même requête avait pas rejoint avant. L'avantage du refactoring permet à l'avenir d'ajouter de nouveaux champs au niveau de l'entraînement ni le niveau d'exercice avec en ajoutant plus double emploi.

des commentaires sur ce débat?

Answer 1

Ne pas supposer que les requêtes seront plus lentes après normalisant. Sur un petit joint plusieurs tables sont très pas cher si les tables sont indexées correctement.

D'autre part, les requêtes sur une table non normalisée peut facilement finir par être beaucoup plus lent. Par exemple, dans votre schéma original, simplement essayer d'interroger les dates distinctes sur lesquelles une séance d'entraînement a été fait est beaucoup plus cher que ce serait avec la version normalisée.

Certainement normalise à ce stade. Si vous rencontrez des problèmes de performance plus tard, alors vous pouvez commencer à dénormaliser sélectivement certaines parties des données en plus au schéma déjà normalisé. Mais selon toute vraisemblance, vous ne serez jamais atteindre ce point avec une petite base de données.

Answer 2

La nouvelle refactorisation semble bonne, et la performance ne sera pas tout ce que vous avez affecté si les indices appropriés sur les différentes tables. (Les index peuvent être créés sur toutes les clés étrangères)

YES , qui semble comme un refactoring parfaitement normal.