我有一个庞大的数据库，在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快速？
答案 0 :(得分：8)
如果你正如你所描述的那样处理一个标准的Lat / Lng对，并且你所做的只是一个简单的查找，那么可以说你不会通过使用几何类型来提高速度。
但是，如果您确实想要更加冒险，那么交换使用几何类型将为您打开全新的可能性，而不仅仅是搜索。
例如（基于我正在处理的项目）你可以（如果是英国数据）下载给定区域的所有城镇/村庄/城市的多边形定义，然后交叉引用以搜索特定区域小镇，或者如果你有路线图，你可以找到哪些顾客住在主要交通路线，高速公路，主要道路旁边的各种各样的东西。
您还可以做一些非常精彩的报道，想象一下城镇地图，每个轮廓都绘制在地图上，然后用颜色着色以显示某个区域中客户的密度，一些简单的几何SQL将很容易归还给您直接从数据库中计算，以绘制此类信息。
然后是跟踪，我不知道你处理什么数据，或者为什么你有客户，但是如果你提供任何东西，喂送货车的坐标，告诉你它与特定客户有多接近
问题是STDistance快吗？好吧，这真的很难说，我认为一个更好的问题是“它与......相比是否快”，很难说是或否，除非你有什么要比较的。
空间索引是将数据移动到地理位置感知数据库的主要原因之一，它们经过优化以便为给定任务生成最佳结果，但与任何数据库一样，如果创建错误索引，则会导致性能下降。
一般来说，你肯定会看到某种速度的提升，因为排序和索引中的数学更能了解数据的用途，而不像普通索引那样在操作中是相当线性的。
请记住，SQL服务器机器越强大，您获得的结果就越好。
最后一点要提到的是数据管理，如果您使用的是GIS感知数据库，则可以打开使用GIS包（如ArcMap或MapInfo）管理，更正和可视化数据的途径，这意味着更正通过指点，点击和拖动很容易做到。
我的建议是为现有的表创建一个并排表格，为空间操作格式化，然后编写一些存储过程并进行一些时序测试，看看哪个是最好的。如果你在基本操作方面有显着的增长，那么这就是理由，如果它大致相同，那么你的决定真的取决于你实际想要实现的新功能。