4

我已经接管了一个存储健身信息的数据库，我们正在就某个表进行辩论，以及它应该保留为一个表还是分成三个表。

今天，有一张名为：锻炼的表格，其中包含以下字段

id、exercise_id、reps、体重、日期、person_id

因此，如果我在一天进行 2 组 3 种不同的练习，那一天的表中将有 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

所以问题是，鉴于多条记录中存在一些冗余数据（日期、人员 ID、锻炼 ID），是否应该将其规范化为三个表

WorkoutSummary :
- id
- date
- person_id

WorkoutExercise :
- id
- exercise_id（WorkoutSummary 中的外键）
- exercise_id

WorkoutSets :
- id
- Fitness_exercise_id (WorkoutExercise 的外键)
- reps
- weight

我想缺点是在重构之后查询会变慢，因为现在我们需要连接 3 个表来执行之前没有连接的相同查询。重构的好处是允许将来在锻炼摘要级别或锻炼级别添加新字段，而无需添加更多重复项。

关于这场辩论的任何反馈？

4

2 回答 2

8

不要假设规范化后查询会变慢。如果表的索引正确，则少量表的连接非常便宜。

另一方面，对非规范化表的查询很容易最终变得慢得多。例如，在您的原始模式中，简单地尝试查询锻炼完成的不同日期比使用规范化版本要昂贵得多。

在这一点上绝对正常化它。如果您稍后遇到性能问题，那么除了已经规范化的模式之外，您还可以开始有选择地对数据的某些部分进行非规范化。但是您很可能永远不会使用小型数据库达到这一点。

于 2010-04-11T16:27:53.413 回答
2

新的重构看起来不错，如果您在各个表上都有适当的索引，性能不会受到太大影响。（可以在所有外键上创建索引）

所以是的，这似乎是一个完全正常的重构。

于 2010-04-11T16:27:11.010 回答