Pourquoi utiliser le type de données géographiques SQL Server 2008?

je suis en train de redessiner une base de données client et l'un des nouveaux éléments d'information que je voudrais stocker avec les champs d'adresse standard (rue, ville, etc.) est l'emplacement géographique de l'adresse. Le seul cas d'utilisation que j'ai à l'esprit est de permettre aux utilisateurs de cartographier les coordonnées sur Google maps lorsque l'adresse ne peut pas être trouvée autrement, ce qui se produit souvent lorsque la zone est nouvellement développée, ou est dans un endroit éloigné/rural.

stocker la latitude et la longitude comme valeurs décimales, mais ensuite je me suis souvenu que SQL Server 2008 R2 a un type de données geography . Je n'ai absolument aucune expérience de l'utilisation de geography , et de mes recherches initiales, il semble être exagéré pour mon scénario.

par exemple, pour travailler avec la latitude et la longitude stockées comme decimal(7,4) , je peux faire ceci:

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

mais avec geography , je ferais ceci:

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

Bien qu'il ne soit pas que beaucoup plus compliqué, pourquoi ajouter complexité si je n'ai pas à le faire?

avant d'abandonner l'idée d'utiliser geography , y a-t-il quelque chose que je devrais considérer? Serait-il plus rapide de chercher un emplacement à l'aide d'un index spatial que d'indexer les champs de Latitude et de Longitude? Y a-t-il des avantages à utiliser geography dont je ne suis pas au courant? Ou, de l'autre côté, y a-t-il des mises en garde que je devrais connaître qui pourraient me décourager d'utiliser geography ?

---

mise à Jour

@Erik Philips a évoqué la possibilité de faire des recherches de proximité avec geography , ce qui est très cool.

par contre, un test rapide montre qu'un simple select pour obtenir la latitude et la longitude est significativement plus lent en utilisant geography (détails ci-dessous). , et un commentaire sur la réponse acceptée à l'autre AFIN que la question sur geography a me méfie:

@SaphuA vous êtes les bienvenus. Comme un sidenote être très prudent d'utiliser un index spatial sur une colonne de type de données géographiques nulles. Il y a quelques problème de performance sérieux, donc rendre cette colonne de géographie non-nullable même si tu dois remodeler ton schéma. - Tomas Jun 18 à 11: 18

en somme, soupesant la probabilité de faire des recherches de proximité par rapport au compromis entre performance et complexité, j'ai décidé de renoncer à l'utilisation de geography dans ce cas.

---

détails de l'essai que j'ai effectué:

j'ai créé deux tableaux, l'un utilisant geography et l'autre utilisant decimal(9,6) pour latitude et longitude:

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

et a inséré une seule ligne en utilisant les mêmes valeurs de latitude et de longitude dans chaque tableau:

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

enfin, l'exécution du code suivant montre que, sur ma machine, sélectionner la latitude et la longitude est environ 5 fois plus lent en utilisant 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

Résultats:

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

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

ce qui est plus surprenant, c'est que même si aucune ligne n'est sélectionnée , par exemple en sélectionnant où RowId = 2 , qui n'existe pas, geography était encore plus lent:

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

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