我已经接管了一个存储健身信息的数据库,我们正在讨论某个表格,以及它是应该保留为一个表还是分成三个表。
今天,有一个名为锻炼的表,其中包含以下字段
id,exercise_id,reps,weight,date,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
所以问题是,鉴于多个记录中存在一些冗余数据(date,personid,exercise_id),是否应将其标准化为三个表
WorkoutSummary :
- id
- 日期
- person_id
WorkoutExercise :
- id
- workout_id(外键进入WorkoutSummary)
- exercise_id
WorkoutSets :
- id
- workout_exercise_id(外键进入WorkoutExercise)
- 代表
- 重量
我猜测的缺点是在重构之后查询会更慢,因为现在我们需要连接3个表来执行之前没有连接的相同查询。重构的好处允许将来在训练摘要级别或练习级别添加新的字段而不添加更多重复。
关于这场辩论的任何反馈意见?
答案 0 :(得分:8)
不要假设规范化后查询会变慢。如果表格被正确编入索引,则加入少量表格非常便宜。
另一方面,非规范化表上的查询很容易变慢。例如,在原始模式中,只是尝试查询完成锻炼的不同日期比使用标准化版本要昂贵得多。
此时肯定将其标准化。如果您稍后遇到性能问题,那么您可以开始有选择地将数据的某些部分另外归一化到已经规范化的模式。但很可能你永远不会通过一个小型数据库达到这一点。
答案 1 :(得分:2)
新的重构似乎很好,如果在各个表上有适当的索引,性能将不会受到影响。 (可以在所有外键上创建索引)
所以是,这似乎是完全正常的重构。