在数据库中跟踪用户位置

Posted 2023-02-16

【中文标题】在数据库中跟踪用户位置

【英文标题】：Tracking User Location in Database

【发布时间】：2016-03-09 11:18:36

【问题描述】：

我正在创建一个应用程序，它将跟踪用户位置并创建与此信息相关的事故单。因此我有以下设置

基本设置

iPhone 应用：跟踪用户位置（纬度、经度）并对信息进行反向地理编码 服务器：用于保存事故单的数据库，包括位置信息

我现在正在努力寻找保存位置信息以跟踪用户和事件的“正确方法”。流程应该如下：

预期方法

正在创建的工单应与给定的信息（例如纬度、经度、地址）一起永久保存，以便我看到发生的事件表 地理信息应该在反向地理编码方面得到有效处理，因为我考虑缓存地址和经纬度信息，这可能不允许谷歌 TOS

应用程序/服务器工作流

Iphone 应用用户点击按钮并执行 POST 请求，将 lat/lng 发送到服务器 服务器系统创建与此请求关联的票证并将此票证信息保存在名为事件的表中

我现在面临的挑战是如何正确处理位置数据的管理，比如地址信息。由于我想使用反向地理编码来获取与纬度和经度信息相关的街道名称，我可以使用 iPhone 或 GoogleMaps API 上的反向地理定位服务。我的第一个问题是：

问题 1)

我是否应该在 iPhone 上反向地理编码并通过 POST 请求将地址信息也发送到服务器并将信息保存在表格中？

问题 2)

在将数据保存到数据库之前，我是否应该只发送 lat/lng 信息并在服务器上进行反向地理编码

我正在努力的下一步是，考虑到数据库规范化，如何有效地将数据保存在数据库中。 目前服务器上发生的事情是：

创建事件

当服务器收到来自应用程序的 POST 请求时，正在创建一个事件票证并将其保存到事件表中 从应用程序发布到服务器的用户 lat/lng 将用于将此信息附加到要保存在数据库中的票证条目

所以当前的表格格式是： 事件（id、incident_reference、address_id、纬度、经度）

现在不知道在哪里保存对应的反向地理编码信息（地址）

问题 3)

是否应将此信息与票证信息本身一起保存？我在那里看到了挑战，因为我会创建冗余信息

所以当前的表格格式是：

incidents (id, incident_reference, latitude, longitude, street_name)

因此，我可以直接使用从 iPhone 应用程序接收到的反向地理编码信息将其直接保存到事件表中。但这不是一个坏习惯吗？我想我会创建多次相同的地址信息，这在数据库规范化方面不是很好吗？不知何故，这似乎不是一个好主意……。

为了找到解决方案，我考虑使用下表设置创建一个单独的地址表：

incidents (id, incident_reference, address_id, latitude, longitude) addresses (address_id, latitude, longitude, street_name)

问题 4)

使用这种方法，我可以想象，然后我可以缓存已经收到的反向地理编码信息，将其保存在数据库中，并在下次查询我的表地址以获取现有地址。我在这里看到的挑战是，可能永远不会有完全相同的纬度/经度，所以我会在表中使用具有不同纬度/经度信息的重复地址条目。

【参考方案1】：

Q1：不，留给服务器，以减少对 iPhone 的影响（带宽使用，电池使用）

第二季度：见第一季度

Q3：见评论

Q4：你的问题是什么？同一地址上的不同事件的纬度/经度是否相同？我非常怀疑。

【讨论】：

抱歉，目前无法评论您的问题。关于 Q3：1 个事件 ID 可以有多个地址吗？

不... 一次事件，一次地址。因此，在使用地址表时，这将是一对多的关系。但是使用单独的表有意义吗？ google dev api 说，建议使用缓存。

Q4：你是对的，它们永远不会相同......嗯......所以缓存没有意义......但是我不创建冗余信息吗？

Q3：您表示1个事件只有1个地址，1个地址可以有多个事件。为了摆脱冗余，您确实会为地址创建一个单独的表并加入它们。

Q4：或者你可以四舍五入纬度/经度，但你最终会得到一个可能错误的地址（邻居）。那么你最好使用冗余地址。