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

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.

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

使用DECIMAL(8,6)表示纬度(90到-90度)，使用DECIMAL(9,6)表示经度(180到-180度)。小数点后6位对于大多数应用程序都是可以的。两者都应该“有符号”以允许为负值。

我们将纬度/经度X 1,000,000作为数字存储在oracle数据库中，以避免使用双数舍入错误。

已知纬度/经度精确到小数点后第6位是10厘米，这就是我们所需要的。许多其他数据库也将lat/long存储到小数点后第6位。

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

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

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

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

Lat Long计算需要精度，因此使用某种类型的十进制类型，并使精度至少比您要存储的数字高2，以便执行数学计算。我不知道我的sql数据类型，但在sql server中，人们经常使用浮点数或实数而不是十进制，这就陷入了麻烦，因为这些是估计值而不是实数。所以只要确保你使用的数据类型是一个真正的十进制类型，而不是一个浮动十进制类型，你就可以了。

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