提问人:David Thielen 提问时间:5/21/2023 更新时间:5/22/2023 访问量:47
存储结构化地址与用户地址的字符串
Storing a structured address vs. a string for a user's address
问:
我正在深入研究使用 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"
};
所以,这里不是征求意见,而是在两种存储数据的方式之间有什么具体的权衡。我能想到的是:
字符串优势
- 数据库架构 - 数据库中的单列。
- U.I. - 自由格式的单个编辑框更快/更容易进入
结构优势
- 获取所有组件
- 明确每个组件是什么
无论使用哪种方法,当用户输入其地址时,我都会将其传递给服务,然后使用返回的已验证地址。
那么还有其他的权衡吗?
答:
如果使用 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 中,并希望根据系统中的地址进行廉价的自动建议,请存储自由格式字符串。如果您对额外的存储空间感到满意,那么存储两者并没有错(除非您使用数千万或更多地址,否则可能相对较小,但即便如此,也可能不是很大的成本。此外,请务必存储纬度/经度值,以便快速加载/可视化。
评论