从一个完全不同和简单的角度来看:

if you are relying on Google for showing your maps, markers, polygons, whatever, then let the calculations be done by Google! you save resources on your server and you simply store the latitude and longitude together as a single string (VARCHAR), E.g.: "-0000.0000001,-0000.000000000000001" (35 length and if a number has more than 7 decimal digits then it gets rounded); if Google returns more than 7 decimal digits per number, you can get that data stored in your string anyway, just in case you want to detect some flees or microbes in the future; you can use their distance matrix or their geometry library for calculating distances or detecting points in certain areas with calls as simple as this: google.maps.geometry.poly.containsLocation(latLng, bermudaTrianglePolygon)) there are plenty of "server-side" APIs you can use (in Python, Ruby on Rails, PHP, CodeIgniter, Laravel, Yii, Zend Framework, etc.) that use Google Maps API.

这样，您就不必担心索引号和与数据类型相关的所有其他问题，这些问题可能会破坏您的坐标。

MySQL使用double为所有浮点数… 所以使用double类型。在大多数情况下，使用float会导致不可预测的四舍五入值

我建议您使用浮动数据类型的SQL Server。

当我从ARINC424构建导航数据库时，我做了相当多的测试，并回顾了代码，我使用了DECIMAL(18,12)(实际上是NUMERIC(18,12)，因为它是firebird)。

浮点数和双精度数没有那么精确，可能会导致舍入错误，这可能是一件非常糟糕的事情。我不记得我是否发现了任何有问题的真实数据——但我相当肯定无法准确地存储在浮点数或双精度数中可能会导致问题

关键是，当使用角度或弧度时，我们知道值的范围——小数部分需要最多的数字。

MySQL空间扩展是一个很好的选择，因为它们遵循OpenGIS几何模型。我没有使用它们，因为我需要保持数据库的可移植性。

PostGIS中的空间函数比MySQL中的空间函数更具功能性(即不局限于BBOX操作)。看看:链接文本

虽然它并不是所有操作的最佳选择，但如果你正在制作地图瓷砖或使用只有一个投影的大量标记(点)(例如Mercator，像谷歌Maps和许多其他滑头地图框架)，我发现我所谓的“巨大坐标系”真的非常非常方便。基本上，你将x和y像素坐标存储在一些放大的地方——我使用缩放级别23。这有几个好处:

You do the expensive lat/lng to mercator pixel transformation once instead of every time you handle the point Getting the tile coordinate from a record given a zoom level takes one right shift. Getting the pixel coordinate from a record takes one right shift and one bitwise AND. The shifts are so lightweight that it is practical to do them in SQL, which means you can do a DISTINCT to return only one record per pixel location, which will cut down on the number records returned by the backend, which means less processing on the front end.

我在最近的一篇博客文章中谈到了这些: http://blog.webfoot.com/2013/03/12/optimizing-map-tile-generation/