Dlaczego warto używać typu danych SQL Server 2008?

Przeprojektowuję bazę klientów i jedną z nowych informacji, które chciałbym przechowywać wraz ze standardowymi polami adresowymi (Ulica, Miasto itp.) jest geograficzną lokalizacją adresu. Jedynym przypadkiem użycia, który mam na myśli, jest umożliwienie użytkownikom mapowania współrzędnych na Mapach Google, gdy adresu nie można znaleźć inaczej, co często zdarza się, gdy obszar jest nowo opracowany lub znajduje się w odległej/wiejskiej lokalizacji.

Moim pierwszym zainteresowaniem było przechowywanie szerokości geograficznej i długość jako wartości dziesiętne, ale potem przypomniałem sobie, że SQL Server 2008 R2 ma typ danych geography. Nie mam absolutnie żadnego doświadczenia w używaniu geography, a z moich wstępnych badań wynika, że jest to przesada dla mojego scenariusza.

Na przykład, aby pracować z szerokością i długością geograficzną zapisaną jako decimal(7,4), mogę to zrobić:

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

Ale z geography, zrobiłbym to:

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

Chociaż to nie jestto znacznie bardziej skomplikowane, po co dodawać złożoności, jeśli nie muszę?

Przed Porzucam pomysł użycia geography, czy jest coś, co powinienem rozważyć? Czy szybsze byłoby wyszukiwanie lokalizacji za pomocą indeksu przestrzennego zamiast indeksowania pól szerokości i długości geograficznej? Czy są jakieś korzyści z używania geography, o których Nie wiem? A z drugiej strony, czy są zastrzeżenia, o których powinienem wiedzieć, które zniechęcają mnie do używania geography?

Update

@Erik Philips wspomniał o możliwości wyszukiwania bliskości z geography, co jest bardzo fajne.

Z drugiej strony, Szybki test pokazuje, że proste select uzyskanie szerokości i długości geograficznej jest znacznie wolniejsze przy użyciu geography (szczegóły poniżej). , a komentarz do zaakceptowanej odpowiedzi na inne tak pytanie na geography mnie leery:

@SaphuA nie ma za co. Jako boczna Uwaga być bardzo ostrożnym z wykorzystaniem indeks przestrzenny w kolumnie nullable GEOGRAPHY datatype. Są pewne poważny problem z wydajnością, więc zrób ten artykuł non-nullable nawet jeśli trzeba przebudować swój schemat. - Tomas Jun 18 at 11: 18

Szczegóły testu, który przeprowadziłem:

Stworzyłem dwie tabele, jedna za pomocą geography, a druga za pomocą decimal(9,6) dla szerokości i długości geograficznej:

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)
) 

I wstawił jeden wiersz używając tej samej szerokości geograficznej i wartości długości geograficznej w każdej tabeli:

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

Wreszcie, uruchomienie poniższego kodu pokazuje, że na moim komputerze wybór szerokości i długości geograficznej jest około 5 razy wolniejszy przy użyciu 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

Wyniki:

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

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

Bardziej zaskakujące jest to, że nawet gdy nie zaznaczono wierszy, na przykład wybierając miejsce RowId = 2, które nie istnieje, geography nadal było wolniejsze:

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

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