关系数据库结构设计

Question

我正在MySQL中设计一个数据库，需要一些关于它应该如何构建以及表之间关系的指导。我已经确定了以下事实：

我有：

• 很多用户。 （精细）
• 一个用户有很多组织。 （一个 - 多个）
• 一个组织有很多活动。 （一个 - 多个）
• 一个用户有很多地址。 （一个 - 多个）
• 一个组织有许多地址（一个 - 多个），但这些地址可能被另一个组织或事件使用。因此，许多组织有许多地址。 （很多 - 很多）
• 一个活动有一个地址。 （一 - 一）
• 一个组织有一个主要地址，但许多组织可能在同一地址工作，所以（很多 - 一个）

这就是我被困住的地方，因为虽然组织或事件有地址，但他们不拥有地址，但用户会这样做。这些关系是否必要？我是否需要定义外键关系，还是可以在没有它们的情况下离开？我是否需要维护一个单独的默认地址表，因为2个组织可以使用相同的地址，但它不是默认地址的一个，因此在地址表中引用它会有问题（哪一个实际上是主要地址）？ / p>

或者我是以太复杂的方式看待这个？也许让用户维护地址，然后当他们添加组织时，组织引用该地址但对其他地址一无所知（组织是一对一的关系还是多个 - 一个用于地址？显然删除了一个组织不应该意味着删除地址，反之亦然。）

然后，当添加事件时，它也只引用一个地址，但可以查找它所属的组织的默认地址。出现与上述相同的问题。事件发生在该地址，但地址不属于该事件，反之亦然。

这几乎简化为：

• 一个用户，很多活动。
• 一个用户，多个组织。
• 一个用户，多个地址。
• 一个组织，一个地址。
• 一个事件，一个地址。

这是查看此问题的正确方法吗？是否有任何可能出现的困难，我似乎没有考虑过？有没有更好的方法来解决这个问题？我遇到的最大问题是如何将表相互关联，以便我可以相应地设置关系。

- 编辑：添加信息

进一步思考，不止一个组织可能会有相同的事件。我希望能够链接事件。这些组织可以由不同的用户添加，但都需要相关。这是MySQL可以轻松处理的事情，还是我应该关注其他类型的数据库逻辑，如图数据库？

Answer 1

这实际上取决于您的使用案例。当然，让用户或组织共享一个地址（因此，地址表）似乎在技术上是正确的，但它可能会增加不必要的复杂性。想想你将如何查询你的数据库（尝试前瞻性思考 - 你以后想做什么？）并设计你的表来支持这些查询。

您的数据库中不必具有外键约束。实际上，我看过的大多数数据库都没有拥有它们，业务逻辑处理检查记录的完整性。我再次建议你务实，并做你喜欢建立和支持的事情。