Should I use SqlGeometry or SqlGeography?
geocoding, geospatial, sql-server
Solution
It's not a question of comparing features, or accuracy, or simplicity - the two spatial datatypes are for working with different sorts of data.
As an analogy, suppose you were choosing the best datatype for a column that contained a unique identifier for each row. If that UID only contained integer values, you'd use int, whereas if it was a 6-character alphanumeric value you'd use char(6). And if it had variable-length unicode values, you'd use nvarchar instead, right?
The same logic goes for spatial data - you choose the appropriate datatype based on the values that that column contains; if you're working with geographic (i.e. latitude/longitude) coordinates, use the SqlGeography datatype. It's that simple.
You can use SqlGeometry to store latitude/longitude values, but it would be like using nvarchar(max) to store an integer... and I promise you it will lead to further problems down the line (when all your area calculations come out measured in degrees squared, for example)
Problem
We're in a bit of internal conflict on this issue, and can't seem to come to a happy conclusion. We'll only be storing latitudes and longitudes, and possibly simple polygons. All we need it for is computing distance between two points (and possibly to see if a point is within a polygon), and the entirety of the data is in such close proximity to make planar estimations acceptable. Since our requirements are so relaxed, half of the dev team suggests using `SqlGeometry` types, which are apparently simpler. I'm having trouble accepting this, though, since we're storing geographic data, which seems like storing them in `SqlGeography` is the right thing to do. Also, I'm not finding any substantive evidence that the `SqlGeometry` data type is that much easier to work with than the `SqlGeography` type. Does anyone have advice as to which type would be more appropriate for this relatively simple scenario?