什么表结构更好？

Question

我正在开发一个多用户任务管理器应用程序，但我偶然发现了数据库架构设计。我有用户表、类别，当然还有任务表。每个任务都属于一个类别。所以用 DDL 的话来说，我需要类别和任务之间的“一对多”关系，对吧？此外，我几乎可以肯定我需要用户和任务实体之间的“一对多”关系。 （如果我错了，请纠正我）。至于“类别-用户”的关系，这里我在认真考虑两个选项，我需要你告诉我哪个是正确的以及为什么：

1. “多对多”关系，即用户可以有多个类别，反之亦然；

2. 每个类别只能与一个用户相关的“一对多”关系。在这种情况下，类别表中将有大量具有相似名称的行，例如“工作”、“家庭”等（因为在类别方面很难想出新的和原创的东西），它们的区别只有“用户”列值。

在这种情况下常见的方法是什么？

Answer 1

这是一个棘手的问题，因为这两种方法都有优势。您可能需要更好地定义您的问题以及您想要完成的任务。

我正在做一个类似的项目，其结构如下：

• 用户表，基本信息
• 一个自相关的任务表，允许创建“项目”（没有父任务）和依赖任务（“在前一个任务完成之前不应开始此任务”）
• 一个多对多分配表，将多个用户连接到多个任务（“这项工作必须由 user1 和 user2 共同完成”）

你的问题又来了：假设用户如何组织他们的待处理任务？

• 如果你的项目更像是一个待办事项列表，你不需要那个分配表；坚持你的“每个任务都属于一个类别”声明
• 如果应允许用户创建自己的类别，您可能需要创建一个user-categories 表，其中包含类别信息和用户表的外键
• 如果用户必须从公共列表中选择以前创建的类别，则不需要该用户 FK
• 无论如何，如果用户可以对自己分配的任务进行分类，那么这个分类表将是分配表中的外键，因此每个用户都可以对自己的任务进行分类

根据我的经验，您应该推迟此类别的决定并询问您的用户；他们会为您指明正确的方向。

您也可以简单地创建 user-catogories 表，因为它比替代方法更灵活，并且忽略数据重复。使用与用户具有多对多关系的基本类别列表可能不是一个好主意，因为用户可能决定重命名一个类别，而所有其他用户都会受到此操作的影响。