Sollte ich SqlGeometry oder SqlGeography verwenden?

Question

Wir befinden uns in diesem Konflikt in einem internen Konflikt und können nicht zu einem glücklichen Ergebnis kommen.

Wir speichern nur Breiten- und Längengrade und möglicherweise einfache Polygone. Alles, was wir dafür benötigen, ist die Berechnung der Entfernung zwischen zwei Punkten (und möglicherweise, um zu sehen, ob ein Punkt innerhalb eines Polygons liegt), und die Gesamtheit der Daten ist so nahe beieinander, dass planare Schätzungen akzeptabel sind.

Da unsere Anforderungen so entspannt sind, schlägt die Hälfte des Entwicklerteams vor, SqlGeometry Typen zu verwenden, die scheinbar einfacher sind. Ich habe jedoch Schwierigkeiten, dies zu akzeptieren, da wir geographische Daten speichern, was scheint, als ob sie in SqlGeography speichern, ist das Richtige zu tun. Ich finde auch keinen substanziellen Beweis, dass der SqlGeometry Datentyp viel einfacher zu bearbeiten ist als der SqlGeography Typ.

Hat jemand einen Rat, welcher Typ für dieses relativ einfache Szenario geeigneter wäre?

Answer 1

Es geht nicht darum, Features, Genauigkeit oder Einfachheit zu vergleichen - die beiden räumlichen Datentypen dienen zum Arbeiten mit verschiedenen Arten von Daten.

Nehmen wir als Analogie an, Sie würden den besten Datentyp für eine Spalte auswählen, die für jede Zeile einen eindeutigen Bezeichner enthält. Wenn diese UID nur ganzzahlige Werte enthält, würden Sie int verwenden. Wenn es sich um einen 6-stelligen alphanumerischen Wert handelt, verwenden Sie char (6). Und wenn es Unicode-Werte variabler Länge hätte, würden Sie stattdessen nvarchar verwenden, richtig?

Die gleiche Logik gilt für räumliche Daten - Sie wählen den geeigneten Datentyp basierend auf den Werten, die diese Spalte enthält; Wenn Sie mit geografischen Koordinaten arbeiten (d. h. geografische Breite/Länge), verwenden Sie den SqlGeography Datentyp. So einfach ist das.

Sie können Verwendung SqlGeometry zu speichern Breite/Länge-Werte, aber es wäre wie mit nvarchar (max) eine ganze Zahl zu speichern ... und ich verspreche Ihnen, es zu weiteren Problemen auf der ganzen Linie führen (wenn alle Ihre Flächenberechnungen zum Beispiel in Quadratquadrate gemessen werden)

Answer 2

Der SqlGeography-Typ verfügt über weniger Methoden als SqlGeometry (besonders in Sql 2008).

SqlGeography reference

SqlGeometry reference

Beispiel: Angenommen, Sie den Schwerpunkt eines Polygons in SQL2008 erhalten möchten. Sie haben dafür eine native Methode in Geometrie, aber nicht in Geografie.

Auch hat es die folgenden Einschränkungen:

• Sie können eine Geographie nicht haben mehr als eine Halbkugel
• Die Ring Ordnung Angelegenheiten, wenn das Polygon zu schaffen

Auch die meisten API und Bibliotheken (die ich kenne) handhaben Geometrien besser als Geographien.

Das heißt, wenn die Entfernungsberechnung genau sein muss, Sie große Entfernungen haben und Koordinaten auf der ganzen Welt haben, würde Geographie besser passen. Andernfalls und entsprechend Ihrer Beschreibung des Problems würden Sie mit dem Geometrietyp gut bedient.

In Bezug auf Ihre Frage: "Ist das viel einfacher zu arbeiten?". Es kommt darauf an. Wie auch immer, und als Faustregel wähle ich für einfache Szenarien normalerweise SqlGeometry.

Wie auch immer, IMHO sollten Sie sich nicht zu viele Gedanken über diese Entscheidung machen. Es ist relativ einfach, eine neue Spalte mit dem anderen Typ zu erstellen und die Daten bei Bedarf zu migrieren.

Answer 3

Vier Jahre später ist es offensichtlich geworden, dass wir die Daten in SqlGeometry anstelle von SqlGeography hätten speichern sollen.

Warum?

Wir importierten Informationen aus Landkarten des Landkreises, und ihre Daten wurden in SqlGeometry gespeichert. Bei der Bestimmung, ob ein bestimmter Breitengrad/Längenbereich innerhalb einer bestimmten legislativen Bezirksgrenze liegt, erhalten wir inkonsistente Ergebnisse, wenn der Punkt nahe zwei Grenzen liegt.

Dies erforderte von uns zusätzliche Arbeiten, um Orte zu identifizieren, die sich in der Nähe einer Grenze befanden, und manuell zu überprüfen, ob sie dem richtigen Bezirk zugewiesen waren. Nicht ideal.

Moral der Geschichte: Wenn Sie sich auf irgendwelche Daten verlassen, überlegen Sie, in welcher Art es gespeichert ist, um Ihre Entscheidung zu leiten.