哪种数据库设计更好？

Question

我即将创建一个数据库来跟踪举重练习。

你更喜欢哪种方法？

解决方案A：

两张桌子

• 练习（带ID，姓名等）
• 设置（带ID，Set_Number，Date，FK_Exercise）

在这里，一个Exercise和Set有一对多的关系。 Set_Number应该跟踪给定日期（第1集，第2集，第3集等）的集合。

优点：一张表少处理。

解决方案B：

三张桌子：

• 练习（带ID，姓名等）
• 会话（带ID，日期，FK_Exercise）
• 设置（带ID，Set_Number，FK_Session）

在这里，Session就像是Exercise和Set之间的连接器。因此，基本上给定练习的给定日期的一系列集合将汇集在一个Session实例中。在这种情况下，Exercise和Session有一对多的关系，Session和Set也有一对多的关系。

优点：Date属性在任何特定日期都不会是多余的。从逻辑上讲，捆绑集合是有意义的。

Answer 1

一个好的数据模型不属于对域的正确理解。您的域名有三个实体：

• 运动：特殊类型的举重运动（名称和重量）
• SET：给定练习的代表数量（取决于训练目标 - 力量，肌肉，耐力？）
• 会议：在给定日期进行的SET数量

所以你至少需要三张桌子。至少，因为EXERCISE有两个细节层次：一个是运动名称，另一个是运动重量。您很可能需要存储不同名称和权重组合的SET（Bicep curl / 10kg，Bicep curl / 15kg等），在这种情况下，您需要一个查找表EXERCISE名称和第四个表SET_EXERCISE来存储用于特定SET的权重销售代表。

经过这个练习（o ho！），我们可以看到你的外键错了。会话包括许多SET; SET包括许多EXERCISE（SET_EXERCISEs）。

因此逻辑数据模型应该类似于：

• 运动（身份证，姓名，体重等）
• SET（ID，FK_Exercise，Reps等）
• 会话（ID，FK_Set，日期等）

虽然这不太准确：SET：SESSION实际上是一个多对多的关系，因为SESSION通常包含多个SET，并且SET可以在多个SESSION中完成。

说到物理数据模型即表格，你应该有五个表格：

• 运动（身份证，姓名等）
• SET_EXERCISE（ID，FK_Exercise，FK_Set，Weight等）
• SET（ID，FK_Set_Exercise，Reps等）
• SESSION_SET（FK_Set，FK_Session，Set_Number等）
• 会话（身份证，日期等）

SESSION_SET表是解析SET和SESSION之间的多对多关系所必需的。

最终模型有五个表：原始实体的三个表和连接这些实体的两个交集表。碰巧逻辑实体（EXERCISE，SET，SESSION）之间的所有关系都已实现为交集表而不是外键。从逻辑数据模型转换为物理数据模型时，并不总是会发生这种情况。

---

这不是建模域的唯一方法。作为设计活动，数据建模是关于interpreting the rules以适合您需要记录的数据。数据是起点。

“似乎我对会话实体没有说清楚......他的命名可能很糟糕并且具有误导性”

这就是为什么我说数据模型来自对域的正确理解。 EXERCISE，SET和SESSION是域名条款。当然，欢迎您为私人项目制定自己的事物定义，但在现实生活中，数据模型是发展与商业之间沟通的机制：事物的意义至关重要，必须符合共同的理解。我们无法建立一个数据模型，其中SESSION意味着与“会话”业务理解的不同。

“我也不明白如何在一个以上的会话中完成一个集合？”

SET是许多代表的EXERCISE模式。所以#1 / benchpress / 130KG / 8 reps是一个SET和#2 / benchpress / 100KG / 12 reps是一个不同的SET。如果你在星期一和星期三进行了八次130KG的压力，那么在两个不同的SESSION中就是相同的SET。也许这是一层细节太过分了;但如果您要构建一个数据库应用来跟踪您的锻炼而不是像大多数人一样使用电子表格，那么您也可以构建最佳数据模型:-)

同样，数据建模是一项具有大量意见的练习：如果您的数据模型足以满足您当前的需求，那么它就足够了。问题是，更严格的数据模型反而更加灵活（因为强制执行数据完整性规则可以更轻松地编写查询并确保结果正确）。现在可能足够好的可能是对未来创新的可怕制约。