Зачем использовать тип данных SQL Server 2008 geography?

я перепроектирую базу данных клиентов и одну из новых частей информации, которую я хотел бы хранить вместе со стандартными полями адресов (улица, город и т. д.)- географическое расположение адреса. Единственный вариант использования, который я имею в виду, - это разрешить пользователям отображать координаты на картах Google, когда адрес не может быть найден, что часто происходит, когда область недавно разработана или находится в удаленном/сельском месте.

мой первый склонялся к тому, чтобы хранить широта и долгота как десятичные значения, но потом я вспомнил, что SQL Server 2008 R2 имеет geography тип данных. У меня нет абсолютно никакого опыта использования geography, и из моего первоначального исследования, это выглядит излишним для моего сценария.

например, для работы с широтой и долготой, сохраненными как decimal(7,4), Я могу сделать это:

insert into Geotest(Latitude, Longitude) values (47.6475, -122.1393)
select Latitude, Longitude from Geotest

но с geography, Я бы сделал так:

insert into Geotest(Geolocation) values (geography::Point(47.6475, -122.1393, 4326))
select Geolocation.Lat, Geolocation.Long from Geotest

хотя не это гораздо сложнее, почему добавить сложность, если мне не нужно?

прежде чем я откажусь от идеи использования geography, есть ли что-нибудь, что я должен рассмотреть? Было бы быстрее искать местоположение, используя пространственный индекс, а не индексировать поля широты и долготы? Есть ли преимущества в использовании geography что я не знаю? Или, с другой стороны, есть предостережения, которые я должен знать о том, что будет препятствовать мне использовать geography?

обновление

@Erik Philips воспитал возможность делать поиск близости с geography, что очень круто.

С другой стороны, быстрый тест показывает, что простой select чтобы получить широту и долготу значительно медленнее при использовании geography (подробности ниже). , и комментарий к принятому ответу на другой так вопрос на geography у меня хитрый:

@SaphuA добро пожаловать. В качестве побочного Примечания будьте очень осторожны с использованием пространственный индекс на ОБНУЛЯЕМОЙ географии столбец типа данных. Есть некоторые серьезная проблема с производительностью, поэтому сделайте этот столбец географии ненулевым даже если вам придется переделывать схему. - Томас 18 июня в 11:18

в целом, взвешивая вероятность выполнения поиска близости против компромисса в производительности и сложности, я решил отказаться от использования geography в этом случае.

подробности теста, который я провел:

я создал две таблицы, одну с помощью geography и еще используя decimal(9,6) для широты и долготы:

CREATE TABLE [dbo].[GeographyTest]
(
    [RowId] [int] IDENTITY(1,1) NOT NULL,
    [Location] [geography] NOT NULL,
    CONSTRAINT [PK_GeographyTest] PRIMARY KEY CLUSTERED ( [RowId] ASC )
) 

CREATE TABLE [dbo].[LatLongTest]
(
    [RowId] [int] IDENTITY(1,1) NOT NULL,
    [Latitude] [decimal](9, 6) NULL,
    [Longitude] [decimal](9, 6) NULL,
    CONSTRAINT [PK_LatLongTest] PRIMARY KEY CLUSTERED ([RowId] ASC)
) 

и вставил одну строку, используя те же значения широты и долготы в каждой таблице:

insert into GeographyTest(Location) values (geography::Point(47.6475, -122.1393, 4326))
insert into LatLongTest(Latitude, Longitude) values (47.6475, -122.1393)

наконец, выполнив следующий код показывает, что на моей машине, выбор широты и долготы примерно в 5 раз медленнее при использовании geography.

declare @lat float, @long float,
        @d datetime2, @repCount int, @trialCount int, 
        @geographyDuration int, @latlongDuration int,
        @trials int = 3, @reps int = 100000

create table #results 
(
    GeographyDuration int,
    LatLongDuration int
)

set @trialCount = 0

while @trialCount < @trials
begin

    set @repCount = 0
    set @d = sysdatetime()

    while @repCount < @reps
    begin
        select @lat = Location.Lat,  @long = Location.Long from GeographyTest where RowId = 1
        set @repCount = @repCount + 1
    end

    set @geographyDuration = datediff(ms, @d, sysdatetime())

    set @repCount = 0
    set @d = sysdatetime()

    while @repCount < @reps
    begin
        select @lat = Latitude,  @long = Longitude from LatLongTest where RowId = 1
        set @repCount = @repCount + 1
    end

    set @latlongDuration = datediff(ms, @d, sysdatetime())

    insert into #results values(@geographyDuration, @latlongDuration)

    set @trialCount = @trialCount + 1

end

select * 
from #results

select avg(GeographyDuration) as AvgGeographyDuration, avg(LatLongDuration) as AvgLatLongDuration
from #results

drop table #results

результаты:

GeographyDuration LatLongDuration
----------------- ---------------
5146              1020
5143              1016
5169              1030

AvgGeographyDuration AvgLatLongDuration
-------------------- ------------------
5152                 1022

что было более удивительно, так это то, что даже когда строки не выбраны, например, выбор где RowId = 2, которого не существует,geography еще медленнее:

GeographyDuration LatLongDuration
----------------- ---------------
1607              948
1610              946
1607              947

AvgGeographyDuration AvgLatLongDuration
-------------------- ------------------
1608                 947