数据库中的共享表，还是多个数据？在数据库中存储真实世界的位置答案

【问题标题】：Shared Table in Database, or Multiple Data? Storing Real-World Location in DB数据库中的共享表，还是多个数据？在数据库中存储真实世界的位置
【发布时间】：2011-02-11 11:53:56
【问题描述】：

我有一个看似简单的问题，但可能比预期的要难。假设我正在尝试跟踪用户和企业的纬度和经度。现在，我有一个名为 locTable 的表，它包含 3 列：索引、纬度、经度。

存储用户和企业信息的表包含 locTable 的 FK。这允许我使用一个表来存储位置数据，但是我注意到对这些数据进行查询可能很困难。

现在，我可以在用户和企业的每个表中存储纬度和经度信息，但是如果我需要对数据进行更改，我必须更新查询以及两个（或更多）不同的表。

大家有什么建议？共享表还是单独存储信息？

【问题讨论】：

标签： database database-design location

【解决方案1】：

首先，确定 lat/long 是否是“查找”表。我不会认为 Lat/Long 是一个查找。这意味着您不会存储所有可能的纬度/经度组合的详尽列表。它们通常指定为小数点后 4 位。理论上，如果你有无限的规模，可能会有无限的纬度/经度组合。

我不会认为在两个表中存储 lat/long 是重复的。想想生日。为避免 BirthDate 重复，您可以创建一个“BirthDates”表，其中包含过去 300 年中每一天的一行。这将避免人、狗和公司的生日重复。但这不是“查找”意义上的重复。

我并不是说将 Lat/Long 存储在它自己的表中是错误的。我只是建议在两个表中存储 Lat/Long 可能不被视为重复。

【讨论】：

是的。我也忘记了城市也有位置。多个位置，如果有意义的话（城市有不同的邮政编码，基于邮政编码）。我只是想知道这些查询实际上是多么的噩梦。例如，试图找出用户和商家之间的距离，如果两者的位置在同一张表中

【解决方案2】：

地点有变化吗？如果是这样，请反转外键。让位置表有一个外键用户和企业表。在位置表中添加日期列，您还可以通过添加新位置随时间跟踪它们。

使用您的模型，您可能必须更新两个表才能更新位置。通过切换外键，您所要做的就是在位置更改时向位置表添加新行。

【讨论】：

理论上，这两个位置都可能发生变化。
那么只需将新行添加到 Location 表中就会使事情变得更容易。用户和企业表根本不必更改。或者，如果您不关心跟踪位置随时间的变化，您可以更新位置行。