我有一个数据库表，其中包含来自Google Maps地理编码响应的地址。 Google缩写所有方向（West - ＆gt; W，East - ＆gt; E等）。
因此，如果我输入“100 West Pender Street”这样的地址，那么Google Maps返回的格式化地址为“100 W Pender St”，我将其插入到我的表格中。
现在，如果用户出现并搜索该地址，则以下所有内容应匹配：
彭德街 西彭德街 100 pender 100 w pender 100 west pender他们或多或少都这样做。然而，表中的“w”被忽略，因为它低于最小字长。落在东柏纳的地址在搜索结果中给予相同的权重（“E”也被忽略）。
处理此问题的最佳方法是什么？
我怀疑将最小字长设置为1是“坏事”。
我可以搜索并替换谷歌地址中的已知缩写（N，E，S，W，St，Ave，Dr等）并将其替换为扩展 - 但是有一些街道名称在哪里这是无效的（一些城市有单字母街道名称：J街等......）
“123 160 St”这样的地址根本无法搜索，因为街道号码（123）和街道名称（160）都低于最小字长。
MySQL FullText是正确的方法吗？ Sphinx能提供更好的服务吗？
或者还有其他我尚未考虑的解决方案吗？请记住，用户的搜索查询不仅会与属性的地址匹配，还会与其他文本列（如属性名称和说明）匹配。
答案 0 :(得分：0)
这实际上是一个非常难以解决的问题 - 如果你是独立的话。我在一家名为SmartyStreets的公司的地址验证行业工作，我们的产品执行您描述的任务。这是一个复杂的操作序列，它将地址搜索与有效的，甚至可交付的端点相匹配。准确，正确，完整地执行地址查找的认证称为CASS认证。
Google的搜索结果与CASS认证结果的区别在于Google的算法是“最佳猜测”。这就是谷歌擅长的......不幸的是，这也适用于那些不完全有效的地址。 （见：http://answers.smartystreets.com/questions/269/why-did-the-address-fail-validation-it-looks-good-to-me）
使用MySQL的模糊查找将产生结果，并且您的代码可以使用算法来提供帮助，但不保证准确性或有效性，或者在这种情况下，甚至任何价值。
我认为您不希望您的用户在返回查询时收到错误的地址。它使您的服务看起来低于标准，用户将无法获得他们期望的价值（对吗？）...我建议您找到CASS软件的供应商。您可以使用谷歌“地址验证” - 我可以推荐的最佳，基于网络的解决方案是SmartyStreets'LiveAddress API。