mysql - 改进我的数据库设计以实现未来的可扩展性

Question

好吧，我正在从事一个可能涉及数千名用户的项目，并且我在数据库方面没有太多经验，尤其是在涉及实体之间的关系时。

让我解释一下我的情况。首先有一个用户可以使用他的凭据登录我们的系统。我们的系统中有一个模块，这将使他能够创建项目。这样就带来了 User 表和 Projects 表之间的关系。

现在有另一个模块，即团队创建模块，它按照它说的做。从可用成员列表中，他可以选择他喜欢的人并将他们添加到团队中。所以有该成员和团队的表格。此外，一个成员可以是许多团队的一部分，一个团队可以有许多成员，“用户”也可以是成员。

我自己设计了一个数据库，但我不确定它是好是坏。此外，如果有人能向我指出如何在涉及关系的表中插入或更新的优秀教程，我将不胜感激。

到目前为止，这是我的设计：

更新

在与 IRC 上的某个人讨论后，我想出了一个修改后的设计。我合并了“用户”和“成员”表，因为用户也是成员。

我的问题仍然是一样的，我在正确的轨道上吗？

Answer 1

长远考虑很好，但您的解决方案不会长期有效。

这不是第一次尝试这种事情。依靠那些曾经搞砸过的人的智慧。阅读数据建模模式书籍。

抽象和规范化。这就是你如何获得一个好的长期解决方案。

至少阅读The Party Model。一个群体和个人实际上是同一个（抽象的）事物。

把不同的东西放在不同的桌子上。地址和成员不属于同一个表。

Answer 2

“我在正确的轨道上吗”不是一个有用的问题——我们无法判断，因为这取决于你的目标。

有几件事：

• 在关系之后命名关系列是个好主意。例如，在第一个图中，项目的“所有者”不应该称为 users_user_id - 这是没有意义的。将其称为“owner_id”或有意义地描述项目和成员表之间关系的名称。
• 在第二张图中，您似乎在 members 表中的成员和项目之间存在“多对多”关系 - 但是没有有效的方法在 members 表中存储多个项目的 id。您需要将其分解到连接表中 - 例如，projects_members，就像您对 teams_members 所做的那样。
• “teams_members”表有一个名为 tm_id 的主键。纯粹主义者会告诉您这是错误的 - 该表的唯一标识符应该是 member_id 和 team_id 的组合。您不需要另一个唯一标识符 - 实际上它是有害的，因为您必须保证 member_id 和 team_id 组合的唯一性。

正如尼尔所说，您可能想开始阅读此内容。我可以推荐 Coronel 等人的“数据库系统：设计、实施和管理”。