【问题标题】:should this database table be normalized?这个数据库表应该被规范化吗?
【发布时间】:2011-02-06 17:52:14
【问题描述】:

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

今天,有一张名为:workouts 的表格,其中包含以下字段

id, exercise_id, reps, weight, date, person_id

因此,如果我在一天内进行 2 组 3 种不同的练习,那一天的表中将有 6 条记录。例如:

id、exports_id、reps、体重、日期、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),是否应该将其规范化为三个表

锻炼总结
- 身份证
- 日期
- person_id

锻炼锻炼
- 身份证
- 锻炼 ID(WorkoutSummary 中的外键)
- 练习 ID

锻炼套装
- 身份证
- Fitness_exercise_id(WorkoutExercise 的外键)
- 代表
- 重量

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

对此辩论有何反馈?

【问题讨论】:

  • 正在使用什么数据库?

标签: sql database-design database-schema database-normalization


【解决方案1】:

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

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

此时一定要对其进行标准化。如果您稍后遇到性能问题,那么您可以开始选择性地对数据的某些部分进行非规范化除了已经规范化的模式。但很可能您永远无法使用小型数据库达到这一点。

【讨论】:

  • @Aaronaught - 你说“如果表格索引正确”。您建议在此处索引哪些字段?
  • @oo:您几乎应该始终索引外键字段(WorkoutExercise 中的workout_idWorkoutSets 中的workout_exercise_id)。根据数据库引擎,您可能希望覆盖部分或全部这些索引。我不确定exercise_id 字段是什么,大概是正在进行的练习类型?如果是这样,如果您计划根据锻炼类型进行查询(“John 一直在跟上深蹲吗?”),那么您可能也需要一个索引。
  • 为将出现在 WHERE 子句中的任何内容添加索引,包括所有主键、候选键和外键。
【解决方案2】:

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

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

【讨论】:

    猜你喜欢
    • 2020-05-08
    • 2018-07-08
    • 2011-07-17
    • 2011-08-26
    • 1970-01-01
    • 2017-04-03
    • 2011-01-06
    • 2017-10-04
    • 1970-01-01
    相关资源
    最近更新 更多