mysql - 在 MySQL 中存储 CLLocationDegrees 时精度丢失

Question

我正在开发一个将 iOS 设备指定的地标 存储到 MySQL 后端的小应用程序。当设备保存新的 Placemark 时，它被插入到数据库中，新生成的 ID 被发送回客户端。如果另一个设备试图保存相同的 Placemark，服务器需要弄清楚它已经存在于数据库中，而不是插入并生成新的 ID，它需要将该地标的现有 ID。

2 Placemarks 如果它们具有相同的:

• 姓名
• 纬度
• 经度

因此，服务器尝试通过发出

来确定提交的地标是否已存在

SELECT id FROM Placemark WHERE name=x, latitude=y, longitude=x

• 在 iOS 中，latitude和 longitude以度为单位，类型为 CLLocationDegrees据<CoreLocation>报道
• 在 MySQL 中，latitude和 longitude定义为 DOUBLE

问题:
存储坐标时会丢失精度，例如:
latidude的 50.09529561485427存储为 50.0952956148543
longitude的 -122.9893130423316存储为 -122.989313042332

问题:
我可以在MySQL中使用不同的数据类型来完整地存储每个坐标吗？

注意事项:

• 我不能将坐标存储为 TEXT或 VARCHAR因为我需要能够说 SELECT placemarks coordinates BETWEEN x AND y , 或执行其他算术 SELECTs
• 我不能使用 MySQL 的空间扩展，因为可移植性是一个问题，而且据我所知，空间数据类型在用作键时非常慢(我的用例需要按坐标选择)

感谢任何帮助

Answer 1

实际上，进一步的测试揭示了以下奇怪的结果:当 DB 驱动程序将数据绑定(bind)到查询语句时，精度会丢失，在数据实际插入到 DB 中。

这有以下有趣的结果:即使我将键绑定(bind)到我的后续搜索查询，精度似乎以相同的方式丢失，因此几乎“意外地”返回了正确的结果。即key(坐标)存错了，然后后面的select也错误的转换了query key，但是是匹配的方式，所以找到了记录。鉴于由于精度损失而导致的转换始终在同一平台(服务器)上执行，因此保留原样可能是安全的？？或者可能不会，也许 future 的迁移练习(即由于缩放)会使舍入误差明显。

Yawar 的指针让我找到了 MySQL 的手册，其中解释了 float 可以存储为 DECIMAL 而不会损失精度:

“精确值数字文字具有整数部分或小数部分，或两者兼而有之。它们可能带有符号” http://dev.mysql.com/doc/refman/5.0/en/precision-math-decimal-changes.html

鉴于现有解决方案似乎可行，那么问题就变成了，是保留数据库数据类型 DOUBLE 还是切换为 DECIMAL 更好？

存储空间:
Latitude 的范围从 -90 到 +90，iOS 似乎使用 14 位小数
的精度Longitude 的范围从 -180 到 +180，这在 iOS 上保留了 13 位小数的精度

这意味着我们需要:
Latitude :DECIMAL(16,14)，它占用的存储空间少于 8 个字节(每包 9d 占用 4 个字节)
经度:DECIMAL(16,13)，也需要少于8字节的存储空间

相比之下，DOUBLE 类型的列需要 8 个字节的存储空间。

速度(算术):
浮点运算几乎总是更快，因为硬件本身就支持它

速度(搜索):
我相信 DECIMAL 的索引与 DOUBLE 的索引具有非常可比的运行时间。

结论:
切换到 DECIMAL 消除了精度错误并降低了存储要求，但算术性能损失在此用例中可以忽略不计。