我有安装了 postgis 扩展的 postgresql 和一个以纬度/经度作为点字段的邮政编码数据表。我希望返回某个 zip 的可变距离内的 zip，例如
返回邮政编码 12345 x 英里范围内的所有邮政编码
大约有 51,000 个邮政编码。预先计算 all 将允许在不计算的情况下进行查找。现在我正在即时进行比较。计算出的数据可以排列在对称矩阵中。
我正在考虑这个解决方案:
如果我们接受 zip 与其自身的距离隐含为零，那么我可以加载一个包含 n^2/2-n 行(大约 13 亿行)、列为 z1 z2 d 的表，然后对 z1+d 执行复合索引以返回包含 z2 列表的查询集。
我的问题是您将如何处理它以实现高效的即时返回。可能在所有距离计算之后放弃sql？让它在查询时如何进行比较？我不太关心完整的距离计算时间或索引时间。我每年都会做这些，或者最多每季度做一次。存储也可能是一个问题？
最佳答案
这是一个有趣的问题。我认为 RDBMS 非常适合这项任务。没必要放弃它。
至于存储预先计算的距离:我只会在确实需要时才这样做，即如果您遇到性能问题。毕竟这是必须维护的冗余数据。如果你决定要这样一张 table ，我同意 Vesper 的观点；存储所有 n^2 行，否则您将始终需要组合两个查询；一个在 z1 中查找您的邮政编码，一个在 z2 中查找。
但也许您可以加快现有查询的速度。我不知道你是怎么处理的。我记得距离的公式相当复杂。所以我要做的就是首先计算所需范围内的极端纬度和经度(即，如果我留在同一纬度，仍在该范围内的最小和最大经度是多少；如果我留在同一经度，什么是最小和最大纬度)。通过计算出的值，您可以使用 BETWEEN 选择该矩形中的所有邮政编码(因此经度和纬度索引可能会派上用场)，然后仅对由此找到的记录使用精确的公式。
编辑:我已经考虑了更多。如果该数据库仅针对您描述的任务而存在，那么是的，为什么不为该特定目的使用另一个表。你提到存储是对的。该表将需要几GB，索引也将占用大量空间。但如果有足够的可用硬盘空间，这应该没有问题。
关于sql - 存储数据对称矩阵的最佳方式 nxn = 26 亿，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23493729/