存储结构化地址与用户地址的字符串

Storing a structured address vs. a string for a user's address

提问人:David Thielen 提问时间:5/21/2023 更新时间:5/22/2023 访问量:47

问:

我正在深入研究使用 Azure Maps 服务,虽然它可以接受 ,但它似乎更喜欢以字符串形式获取地址。换句话说,它想要:StructuredAddress

var addr = "15127 NE 24th Street, Redmond, WA 98052 US"

而不是:

var address = new StructuredAddress
{
    CountryCode = "US",
    StreetNumber = "15127",
    StreetName = "NE 24th Street",
    Municipality = "Redmond",
    CountrySubdivision = "WA",
    PostalCode = "98052"
};

所以,这里不是征求意见,而是在两种存储数据的方式之间有什么具体的权衡。我能想到的是:

字符串优势

  1. 数据库架构 - 数据库中的单列。
  2. U.I. - 自由格式的单个编辑框更快/更容易进入

结构优势

  1. 获取所有组件
  2. 明确每个组件是什么

无论使用哪种方法,当用户输入其地址时,我都会将其传递给服务,然后使用返回的已验证地址。

那么还有其他的权衡吗?

地理空间 街道地址 azure-maps

评论


答:

0赞 rbrundritt 5/22/2023 #1

如果使用 Azure Maps V2 搜索地理编码服务,则在后台它会利用必应地图地理编码器。众所周知,该地理编码器在处理自由格式地址字符串时的性能优于结构化地址。这记录在以下 Bing 地图文档中:https://learn.microsoft.com/en-us/bingmaps/getting-started/bing-maps-api-best-practices#use-the-find-by-query-api“推荐的方法是使用按查询查找 API 将地址作为单行查询传入”,其中“按查询查找”API 是必应地图自由格式地址字符串地理编码器 API。我怀疑此见解尚未进入 Azure Maps 文档,因为此 API 仍处于预览状态。

至于存储,存储的内容和方式应基于您的场景的需要。如果您需要访问地址的某些部分,请存储该地址。如果只需要地址字符串,请存储该字符串。如果用户将地址字符串传递到 UI 中,并希望根据系统中的地址进行廉价的自动建议,请存储自由格式字符串。如果您对额外的存储空间感到满意,那么存储两者并没有错(除非您使用数千万或更多地址,否则可能相对较小,但即便如此,也可能不是很大的成本。此外,请务必存储纬度/经度值,以便快速加载/可视化。