Wenn Sie planen, räumliche Berechnungen durchzuführen, erlaubt EF 5.0 LINQ-Ausdrücke wie:
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();
}
Dann gibt es einen sehr guten Grund, Geographie zu verwenden.
Erklärung von Spatial in Entity Framework .
Aktualisiert mit Erstellen von räumlichen Hochleistungsdatenbanken
Wie ich auf Antwort von Noel Abraham angemerkt habe :
Vergleichen Sie also Speichertypen:
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'
Ergebnis:
name rows data
Geo 20000 728 KB
LatLon 20000 560 KB
Der Datentyp "Geographie" nimmt 30 % mehr Platz ein.
Außerdem ist der geografische Datentyp nicht darauf beschränkt, nur einen Punkt zu speichern, Sie können auch speichern LineString, CircularString, CompoundCurve, Polygon, CurvePolygon, GeometryCollection, MultiPoint, MultiLineString und MultiPolygon und mehr . Jeder Versuch, selbst die einfachsten Geografietypen (als Lat/Long) über einen Punkt hinaus zu speichern (z. B. LINESTRING(1 1, 2 2)-Instanz), führt zu zusätzlichen Zeilen für jeden Punkt, einer Spalte zur Sequenzierung für die Reihenfolge jedes Punkts und eine weitere Spalte zum Gruppieren von Zeilen. SQL Server verfügt auch über Methoden für die Datentypen Geographie, die die Berechnung von Fläche, Grenze, Länge, Entfernungen und mehr .
Es erscheint unklug, Längen- und Breitengrad in Sql Server als Dezimalzahl zu speichern.
Aktualisierung 2
Wenn Sie vorhaben, Berechnungen wie Entfernung, Fläche usw. durchzuführen, ist es schwierig, diese über die Erdoberfläche richtig zu berechnen. Jeder in SQL Server gespeicherte Geografietyp wird auch mit einer Raumbezugs-ID gespeichert . Diese IDs können aus verschiedenen Sphären stammen (die Erde ist 4326). Das bedeutet, dass die Berechnungen in SQL Server tatsächlich korrekt über der Erdoberfläche (statt as- die-krähen was durch die Erdoberfläche sein könnte).
