用户平面位置数据库设计解决方案

Posted 2023-04-12

【中文标题】用户平面位置数据库设计解决方案

【英文标题】：User-Place-Location database design solutuin

【发布时间】：2015-08-22 12:11:03

【问题描述】：

我有点困惑如何设计关于关系的数据库。

我的用户可能有很多位置。 （跟踪用户位置） 我有一个可以有很多位置的地方。 （地点可以是酒吧、餐厅、医院……地点很多 - （例如，麦当劳是一个小屋酒吧，在世界各地都有很多地点）

我的困惑是用户--> 位置和地点--> 位置之间的关系。我不确定我的想法是否正确。

用户可以有多个位置，但位置可以有我的用户、餐馆。 Place 可以与多个 Location 相关联，但 Location 可以有多个地点（例如，同一建筑物中的两个酒吧具有相同的 lat、lng）。

在（用户、位置）和（地点、位置）两种情况下设计具有多对多关系的数据库是否正确？

【问题讨论】：

你能举例说明数据是什么样的吗？例如，location 是什么？一组 GPS 坐标、年历中的名称、网格上的近似值，还是什么？

Location 是一组 lat,lng。

假设你不能在同一个位置有两个地方，即 1:many。

如果 Location 只是 lat+lng，那么不要将它分开到不同的表中。

【参考方案1】：

对于多对多关系，您应该有一个“中间表”，它只引用相关表的主键。在您的情况下，您有一张 USERS 和 LOCATIONS 的表格：

USERS:
pkUsers, userName, userPhone ... etc.

LOCATIONS:
pkLocation, street, city ... etc.

其中pkUsers 和pkLocation 是主要的自动增量ID

中间的表格应该类似于USERLOCATIONS，有两个字段：

USERLOCATIONS
fkUsers, fkLocations

（其中'fk'代表外键）

现在，当位置和用户关联时，只需将它们的主键添加到表中。

您可以对 RESTAURANTS 或任何其他多对多表执行相同操作。

【讨论】：

谢谢！ User-Location OneToMany 关系呢？如果我选择这种关系而不是 ManyToMany，我会失去什么？

您仍然可以像往常一样在两个原始字段中建立一对多的关系。这种设计仅对多对多是必需的。因此，在USERS 表中，您可以有一个字段fkTitle，它指向TITLE 表中的一个人的头衔（假设用户只能拥有一个头衔）。

如果您觉得这回答了您的问题或有用，请接受答案并投票。谢谢！