Waarom het geografische gegevenstype SQL Server 2008 gebruiken?

Als je van plan bent om ruimtelijke berekeningen uit te voeren, staat EF 5.0 LINQ-expressies toe zoals:

private Facility GetNearestFacilityToJobsite(DbGeography jobsite)
{   
    var q1 = from f in context.Facilities            
             let distance = f.Geocode.Distance(jobsite)
             where distance < 500 * 1609.344     
             orderby distance 
             select f;   
    return q1.FirstOrDefault();
}

Dan is er een hele goede reden om Aardrijkskunde te gebruiken.

Uitleg van ruimtelijk binnen Entity Framework .

Bijgewerkt met High-performance ruimtelijke databases maken

Zoals ik opmerkte op Antwoord van Noel Abraham :

Dus opslagtypes vergelijken:

CREATE TABLE dbo.Geo
(    
geo geography
)
GO

CREATE TABLE dbo.LatLng
(    
    lat decimal(15, 12),   
    lng decimal(15, 12)
)
GO

INSERT dbo.Geo
SELECT geography::Point(12.3456789012345, 12.3456789012345, 4326) 
UNION ALL
SELECT geography::Point(87.6543210987654, 87.6543210987654, 4326) 

GO 10000

INSERT dbo.LatLng
SELECT  12.3456789012345, 12.3456789012345 
UNION
SELECT 87.6543210987654, 87.6543210987654

GO 10000

EXEC sp_spaceused 'dbo.Geo'

EXEC sp_spaceused 'dbo.LatLng'

Resultaat:

name    rows    data     
Geo     20000   728 KB   
LatLon  20000   560 KB

Het datatype geografie neemt 30% meer ruimte in beslag.

Bovendien is het geografische datatype niet beperkt tot alleen het opslaan van een punt, u kunt ook opslaan LineString, CircularString, CompoundCurve, Polygon, CurvePolygon, GeometryCollection, MultiPoint, MultiLineString en MultiPolygon en meer . Elke poging om zelfs de eenvoudigste aardrijkskundetypen (als Lat/Long) buiten een punt op te slaan (bijvoorbeeld LINESTRING(1 1, 2 2) instantie) zal extra rijen opleveren voor elk punt, een kolom voor het rangschikken van de volgorde van elk punt en een andere kolom voor het groeperen van lijnen. SQL Server heeft ook methoden voor de gegevenstypen Geografie, waaronder het berekenen van Area, Boundary, Lengte, afstanden en meer .

Het lijkt onverstandig om Latitude en Longitude als decimaal op te slaan in Sql Server.

Update 2

Als u van plan bent berekeningen te doen zoals afstand, oppervlakte, enz., is het moeilijk om deze over het aardoppervlak goed te berekenen. Elk type geografie dat is opgeslagen in SQL Server wordt ook opgeslagen met een Spatial Reference ID . Deze id's kunnen van verschillende sferen zijn (de aarde is 4326). Dit betekent dat de berekeningen in SQL Server daadwerkelijk correct over het aardoppervlak zullen worden berekend (in plaats van as- the-crow-flies die door het aardoppervlak zou kunnen zijn).