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

【问题标题】：Improving my Database Design for future scalability改进我的数据库设计以实现未来的可扩展性
【发布时间】：2013-11-28 03:29:59
【问题描述】：

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

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

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

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

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

更新

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

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

【问题讨论】：

是的，你基本上走上了正轨。然而，一个成员真的只能是一个且只有一个项目的一部分吗？那里不应该是多对多的关系吗？您还应该定义自然键。 en.wikipedia.org/wiki/Natural_key
@JonBoulineau 这是一个有趣的问题（我以前没想过；关于成员和项目之间是否也应该存在多对多关系，这有点发人深省）。一个会员可以创建许多项目，也可以成为其他许多项目的一部分（我想也包括他的项目）。

【解决方案1】：

您的想法很长远，但您的解决方案不会长期有效。

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

抽象和规范化。这样才能找到一个好的长期解决方案。

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

将不同的东西放在不同的表中。地址和成员不属于同一个表。

【讨论】：

【解决方案2】：

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

有几点：

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

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

【讨论】：