我有一个充满客户的大型数据库,在sql server 2005中实现.每个客户都有一个纬度和经度,表示为Decimal(18,15).数据库中最重要的搜索查询会尝试查找靠近某个位置的所有客户,如下所示:
(Addresses.Latitude - @SearchInLat) BETWEEN -1 * @LatitudeBound AND @LatitudeBound)
AND ( (Addresses.Longitude - @SearchInLng) BETWEEN -1 * @LongitudeBound AND @LongitudeBound)
所以,这是一种非常简单的方法.@LatitudeBound并且@LongitudeBound只是数字,用于拉回该点的粗略边界矩形内的所有客户@SearchInLat, @SearchInLng.一旦结果到达客户端PC,就会过滤掉一些结果,以便有一个边界圆而不是一个矩形.(这是在客户端PC上完成的,以避免计算服务器上的平方根.)
这种方法过去运作良好.但是,我们现在想让搜索做更多有趣的事情 - 例如,拉回结果的数量更可预测,或者让用户动态增加搜索半径的大小.为此,我一直在研究使用Geography数据类型,空间索引和距离函数对sql server 2008进行ugprading的可能性.我的问题是:这些有多快？
我们目前的简单查询的优点是它非常快且不是性能密集型,这很重要,因为它经常被调用.查询基于这样的速度有多快:
SearchInPoint.STDistance(Addresses.GeographicPoint) < @DistanceBound
相比之下？空间索引是否运作良好,并且STDistance快速？
如果你正如你所描述的那样处理一个标准的Lat/Lng对,并且你所做的只是一个简单的查找,那么可以说你不会通过使用几何类型来提高速度.
但是,如果您确实希望在您声明时获得更多冒险,那么交换使用几何类型将为您打开一个全新的可能性,而不仅仅是搜索.
例如(根据我正在研究的项目),您可以(如果是英国数据)下载给定区域的所有城镇/村庄/城市的多边形定义,然后在特定城镇进行交叉引用搜索,或者如果您有路线图,您可以找到哪些客户住在主要交付路线,高速公路,主要道路旁边的各种各样的东西.
您还可以做一些非常精美的报道,想象一下城镇地图,每个轮廓都绘制在地图上,然后用颜色着色以显示区域内客户的密度,一些简单的几何SQL将很容易让您直接计算从数据库中,绘制这种信息.
然后是跟踪,我不知道你处理什么数据,或者为什么你有客户,但是如果你提供任何东西,喂送货车的坐标,告诉你它与给定客户有多接近.
至于问题是STDistance快吗？好吧,这真的很难说,我认为一个更好的问题是"它与......相比是否快",很难说是或否,除非你有什么要比较的.
空间索引是将数据移动到地理位置感知数据库的主要原因之一,它们经过优化以便为给定任务生成最佳结果,但与任何数据库一样,如果创建错误索引,则会导致性能下降.
一般来说,你肯定会看到某种速度的增加,因为排序和索引中的数学更能意识到数据的目的,而不像普通索引那样只是在运算中是相当线性的.
请记住,SQL服务器机器越强大,您将获得更好的结果.
最后要提到的是数据管理,如果您使用GIS感知数据库,那么打开了使用GIS包(如ArcMap或MapInfo)来管理,纠正和可视化数据的途径,这意味着更正非常容易通过指向,单击和拖动来完成.
我的建议是为现有的表格创建一个并排表格,格式化为空间操作,然后编写一些存储过程并进行一些计时测试,看看哪个是最好的.如果你在基本操作上有显着的增长,那么这就是理由,如果它大致相同,那么你的决定真的取决于你实际想要实现的新功能.