¿Qué tan bueno es el tipo de datos de geografía en el servidor sql 2008?

Question

Tengo una gran base de datos llena de clientes, implementada en el servidor SQL 2005. Cada cliente tiene una latitud y longitud, representadas como Decimal(18,15). La consulta de búsqueda más importante de la base de datos intenta encontrar todos los clientes cerca de un lugar determinado de esta manera:

(Addresses.Latitude - @SearchInLat) BETWEEN -1 * @LatitudeBound AND @LatitudeBound) 
AND ((Addresses.Longitude - @SearchInLng) BETWEEN -1 * @LongitudeBound AND @LongitudeBound) 

Por lo tanto, este es un método muy simple. @LatitudeBound y @LongitudeBound son solo números, utilizados para retirar a todos los clientes dentro de un rectángulo delimitador aproximado del punto @SearchInLat, @SearchInLng. Una vez que los resultados llegan a la PC del cliente, algunos resultados se filtran para que haya un círculo delimitador en lugar de un rectángulo. (Esto se hace en la PC del cliente para evitar el cálculo de raíces cuadradas en el servidor).

Este método ya funcionó bastante bien en el pasado. Sin embargo, ahora queremos hacer que la búsqueda haga más cosas interesantes, por ejemplo, tener la cantidad de resultados retraídos sea más predecible, o para que el usuario aumente dinámicamente el tamaño del radio de búsqueda. Para hacer esto, he estado buscando la posibilidad de ugprading al servidor sql 2008, con su tipo de datos Geography, índices espaciales y funciones de distancia. Mi pregunta es esta: ¿qué tan rápido son estos?

La ventaja de la consulta simple que tenemos en este momento es que es muy rápida y no requiere mucho rendimiento, lo cual es importante ya que se llama con mucha frecuencia. ¿Qué tan rápido sería una consulta basada en algo como esto:

SearchInPoint.STDistance(Addresses.GeographicPoint) < @DistanceBound 

ser por comparación? ¿Funcionan bien los índices espaciales y es rápida la distancia ST?

Answer 1

Si maneja solo un par de Lat/Lng estándar como usted describe, y todo lo que hace es una búsqueda simple, entonces posiblemente no gane mucho en el aumento de velocidad usando el Tipo de Geometría.

Sin embargo, si desea ser más audaz como lo indica, el cambio a usar los tipos de Geometría le abrirá todo un mundo de nuevas posibilidades, y no solo para las búsquedas.

Por ejemplo (basado en un proyecto en el que estoy trabajando) puede (si es datos del Reino Unido) descargar las definiciones de polígono para todas las ciudades/pueblos/ciudades para un área determinada, luego hacer referencias cruzadas para buscar en un en particular, o si tenía una hoja de ruta, podría encontrar qué clientes vivían cerca de las principales rutas de entrega, autopistas, carreteras principales, todo tipo de cosas.

También podría hacer algunos informes muy elaborados, imagine un mapa de ciudades, donde cada contorno se trazó en un mapa, luego sombreado con un color para mostrar la densidad de clientes en un área, algunos SQL de geometría simple fácilmente regresarán usted cuenta directamente desde la base de datos, para graficar este tipo de información.

Luego está el rastreo, no sé qué datos maneja, o por qué tiene clientes, pero si entrega algo, alimenta las coordenadas de una furgoneta de reparto, le dice qué tan cerca está de un determinado cliente.

En cuanto a la pregunta, ¿es STDistance fast? bueno, eso es difícil de decir, creo que una pregunta mejor es "¿Es rápido en comparación con ...?", es difícil decir sí o no, a menos que tengas algo con lo que compararlo.

Los índices espaciales son una de las principales razones para mover sus datos a bases de datos geográficamente optimizados para obtener los mejores resultados para una tarea determinada, pero como cualquier base de datos, si crea índices incorrectos, obtendrá un mal rendimiento .

En general, definitivamente debería ver un aumento de velocidad de algún tipo, porque las matemáticas en la clasificación e indexación son más conscientes del propósito de los datos en lugar de ser bastante lineales en operación como lo es un índice normal.

Tenga en cuenta también que cuanto más robusta es la máquina del servidor SQL, mejores resultados obtendrá.

Un último punto para mencionar es la gestión de los datos, si utiliza una base de datos GIS, entonces abre la posibilidad de utilizar un paquete GIS como ArcMap o MapInfo para gestionar, corregir y visualizar sus datos, lo que significa las correcciones son muy fáciles de hacer apuntando, haciendo clic y arrastrando.

Mi consejo sería crear una tabla contigua a la existente, que esté formateada para operaciones espaciales, luego escribir algunos procesos almacenados y hacer algunas pruebas de tiempo, ver cuál sale mejor. Si usted tiene un aumento significativo solo en las operaciones básicas que realiza, entonces esa es solo la justificación, si es casi igual que la decisión realmente depende de qué nueva funcionalidad realmente desea lograr.