我正在创建用于监控应用程序功能状态的数据库。逻辑如下：

每个应用程序都有自己的特定功能列表，我正在监控这些功能。每个功能只属于一个应用程序。有一个具有应用程序外键的功能表

每个应用程序都在一台或多台机器上运行。每台机器都可以运行一个或多个应用程序。这是MTM连接，所以有ApplicationInstance表连接Applications with Machines。

实际监控是查询ApplicationInstance。如果有问题，有关它的信息将转到 AppInstanceError 表，该表包含 ApplicationInstance 的外键。如果查询成功，我们会得到每个功能的状态列表。所以我们有一个功能状态表，其中包含应用程序实例和功能的外键。

我认为这是一种糟糕的设计——为什么我们要多次引用应用程序？什么保证两者都指向同一个应用程序？或者有什么办法可以确保这一点？

所以我的修复建议是将功能状态与机器和功能的外键连接起来。但是在这种情况下，他们定义了 ApplicationInstance 那么每对都有 ApplicationInstance 的保证是什么？他们不应该以某种方式连接吗？在现实世界中存在连接并且是显而易见的，那么数据库中没有它可以吗？

是否有解决这个问题的“正确方法”，或者确保连接从数据设计中不可见？

为了更清楚，我准备了我现在拥有的数据库设计：

唯一缺少的是从功能状态到机器的连接。我看到了两种建立这种联系的方法：

1. 将外键添加到 ApplicationInstance - 那么我的疑问是：
   • 如何确保功能中的 ApplicationId 与 ApplicationInstance 中的相同？
   • 真的需要这种数据复制吗？
2. 将外键添加到机器 - 和疑问：
   • 每个功能状态记录都会有一个适当的 ApplicationInstance 记录吗？
   • 如果 ApplicationInstance 和 FunctionalityStatus 之间有明显的联系（在第一个疑问中提到）我们不能在数据库中看到它吗？
   • 再次数据冗余，因为所有 ApplicationInstance 记录都（或应该）在 FunctionalityStatus 表中可见

或者，也许整个设计都搞砸了，我应该找出完全不同的东西？

背景

我是 CS 一年级的学生，我为我父亲的小企业做兼职。我在现实世界的应用程序开发方面没有任何经验。我用 Python 写过脚本，用 C 写过一些课程，但没有这样的东西。

我父亲有一家小型培训公司，目前所有课程都通过外部 Web 应用程序安排、记录和跟进。有一个导出/“报告”功能，但它非常通用，我们需要特定的报告。我们无权访问实际数据库来运行查询。我被要求建立一个自定义报告系统。

我的想法是创建通用的 CSV 导出并将它们导入（可能使用 Python）到每晚托管在办公室的 MySQL 数据库中，从那里我可以运行所需的特定查询。我没有数据库方面的经验，但了解非常基础的知识。我已经阅读了一些关于数据库创建和普通表单的内容。

我们可能很快就会开始拥有国际客户，所以我希望数据库在发生这种情况时不会爆炸。我们目前还有几家大公司作为客户，拥有不同的部门（例如 ACME 母公司、ACME 医疗保健部门、ACME 身体护理部门）

我想出的架构如下：

1. 从客户的角度来看：
   • 客户是主表
   • 客户与他们工作的部门相关联
     • 部门可以分散在一个国家/地区：伦敦的人力资源部，斯旺西的营销部等。
     • 部门与公司的部门相关联
   • 部门与母公司相关联
2. 从类的角度来看：
   • 会话是主表
     • 每节课都有一位老师
     • 每个会话都有一个 statusid。例如 0 - 已完成，1 - 已取消
     • 会话被分组为任意大小的“包”
   • 每个包都分配给一个客户

我在一张纸上“设计”（更像是潦草）模式，试图将其规范化为第三种形式。然后我将它插入 MySQL Workbench，它对我来说很漂亮：（
单击此处查看全尺寸图形）

_{（来源：maian.org）}

我将运行的示例查询

• 哪些仍有信用的客户处于非活动状态（未来没有安排课程的客户）
• 每个客户/部门/部门的出勤率是多少（以每个会话中的状态 ID 衡量）
• 一个老师一个月有多少节课
• 标记出勤率低的客户
• 人力资源部门的自定义报告，包含其部门人员的出勤率

问题）

• 这是过度设计还是我走对了路？
• 大多数查询需要连接多个表会导致性能大幅下降吗？
• 我已经向客户添加了一个“lastsession”列，因为它可能是一个常见的查询。这是一个好主意还是我应该严格规范数据库？

谢谢你的时间

我了解数据库规范化的概念，但总是很难用简单的英语解释它——尤其是在面试时。我已经阅读了维基百科的帖子，但仍然很难向非开发人员解释这个概念。“以不获取重复数据的方式设计数据库”是首先想到的。

有没有人有一个很好的方法来用简单的英语解释数据库规范化的概念？有哪些很好的例子来说明第一范式、第二范式和第三范式之间的区别？

假设你去参加工作面试，面试官问： 解释规范化的概念以及如何设计规范化数据库。

面试官在寻找哪些关键点？

假设我在数据库上有两个表 T ₁₀和 T ₁₁，分别有 10 和 11 列，其中 10 列在两者上完全相同。

我违反了什么（如果有）规范化规则？

我有三个表：帖子、附件和媒体。

帖子有附件，附件有媒体。

目前，Post 和 Attachment 表是通过外键链接的，Attachment 和 Media 表也是如此。我的问题是，为了正确的数据库设计和规范化，我应该在 Post 和 Media 之间设置外键关系吗？我不确定我应该将这些表链接到多深。

谢谢

我有一个自由 Web 应用程序，可让用户注册活动。在我的数据库中，我有一个 t_events_applicants 表，其中包含 t_events_applications.user_id 列，外键约束链接到 t_users.user_id 列。所以这意味着只有注册了我的 Web 应用程序的用户才能注册我的 Web 应用程序的事件。

我的客户现在希望允许未注册用户，即在我的 t_user 表中没有条目的用户注册事件。这些非注册用户只需要提供他们的姓名和电子邮件地址即可注册活动。

我应该创建一个包含列名称和电子邮件的 t_temporary_user 表，然后删除 t_events_applicants.user_id fk 约束吗？或者我应该将未注册的用户添加到 t_user 表中，然后添加一个名为 t_user.type 的列，其中类型可以是“已注册”或“未注册”？

我如何决定采用哪种方法？

很多时候，我对任何一种方法都犹豫不决。我问自己，“如果以后允许一个临时用户成为一个完全注册的用户怎么办？那么也许我应该只有一个 t_user 表。但是我也不觉得存储很多临时用户好在 t_user 中。”

我正在存储有关棒球统计数据的数据，并希望使用三个表来存储：players、battingStats 和 pitchingStats。出于问题的目的，每个球员都会有击球数据或投球数据，但不能同时拥有。

我将如何在 3NF 中规范这种关系？

由于我在 1-2 年的经验中，我应该对这个面试问题说些什么......

规范化的类型有哪些？我应该说所有的正常形式还是什么？

一个客户可以有多个电话号码，例如 Cell、Work 等。Customer 表中的 phoneID 是唯一的，并且指向 Phone 表中的 PhoneID。如果客户记录被删除，Phone 表中的 phoneID 也应该被删除。

你对我的设计有任何顾虑吗？这设计得当吗？我的问题是 Customer 表中的 phoneID 是一个孩子，如果删除了子记录，那么我无法自动删除父（电话）记录。

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

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

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 个表来执行之前没有连接的相同查询。重构的好处是允许将来在锻炼摘要级别或锻炼级别添加新字段，而无需添加更多重复项。

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