PostgreSQL与MySQL：空间特征比较

我们正在构建具有空间数据组件的Web应用程序。首先，我们的空间数据比较将获取一个给定的点，并返回匹配的重叠空间多边形。

话虽如此，我们的数据库还有许多其他组件，其中包括您在常规关系数据库中可以找到的所有典型内容。

在项目中，我们必须选择要使用的数据库解决方案。

所有项目成员都对MySQL的实现和管理更加熟悉，但是所有研究表明PostgreSQL是更好的解决方案-特别是在使用postGIS的空间数据方面。

我们期望（希望）我们的应用程序在许多并发用户中会经历很多动作。

是否有任何将MySQL用作具有空间数据组件的RDBMS的经验的人有长期的建议/经验？

除熟悉之外，使用PostGIS是否有任何缺点？

我不能说相对于MySQL的优点/缺点，但是PostGIS代码被广泛认为是最好的（就速度/功能而言）和最成熟的（就测试/实际暴露而言）之一。 ）可用。

举例来说，来自FAA的一些人在PGEast 2010上进行了一次演讲，他们将他们的机场数据库（由AeroNav和其他人用来编译图表）从Oracle转换为Postgres / PostGIS。
该avationDB网站也是建立在Postgres的（8.0）的顶部。

如果与GIS相关的查询是您正在做的工作的核心，我的建议是选择Postgres。它当然也可以处理您通常在关系数据库中所做的所有其他事情。

就从MySQL进行切换而言，Postgres背后的文档是一流的，并且Oostgres Wiki中还有一部分内容涉及从MySQL切换到Postgres。
最初的学习曲线可能会有些陡峭，您可能需要调整数据库和任何存储过程（如果您已经为MySQL编写了它们），但这并不是一个不可克服的任务。

您应该有足够的能力在几周内完成切换，如果您建立了开发数据库，​​则您可能会在一个月内精通日常任务，并确信您知道该手册的内容。对于不太常规的。

说到一些非常重要的事情。这是MySQL和MariaDB完全不存在的PostGIS支持的列表。

• 计算中的SRID，为您的点赋予其他SRID，您将获得不同的值。这是支持聚合功能：据我所知，MySQL没有提供空间聚合功能

K最近邻居：仅PostGIS支持KNN。仅使用索引即可找到最接近任何点的点：无需计算所有点的距离！MySQL违反规范，仅检查两个值具有相同的SRID。PostGIS带有pro4j定义的数据库，以实现无缝SRID感知。设置SRID并调用ST_Transform（MySQL缺少的函数）将重新投影您的坐标。

在MySQL中，无论实际SRID值如何，所有计算都假定SRID 0。SRID 0表示无限平坦的笛卡尔平面，其轴未分配任何单位。将来，计算可能会使用指定的SRID值。为确保SRID 0行为，请使用SRID 0创建几何值。如果未指定SRID，则新几何值的默认SRID 0是默认值。

• 栅格：从栅格生成到提取，这里有很多功能。您可以生成热图等。

• 地理，PostGIS支持一种完全不使用笛卡尔数学的非投影地理类型。它具有在扁球形上运行的相关函数的整体速度。相反，MySQL甚至不能从两点在地理SRS中创建边界框。

• 拓扑与矢量几何不同，拓扑几何存储节点和关系。移动节点，边缘也移动，您会得到一张新面孔。这也迫使边缘被定向，使其成为布线的理想选择。作为子点，MySQL无法使用PgRouting所做的100％的操作，因此您无法在其上创建Google Maps等。

• 地理编码：contrib目录中存在地理编码器扩展，用于处理普查数据，而加载程序用于安装该数据。

• 地址标准化：有一个扩展程序可以处理标准化地址，以便于解析，存储和比较。

• SQL-MM功能，您根本找不到CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVE或MULTISURFACE在MySQL中找到。

• 提示：PostGIS可以支持3dm，3dz和4d形状，而MySQL 根本无法支持这些点

• MySQL仅支持r树索引。PostGIS支持r树（主键/杜松子酒）和BRIN（用于大型几何表）

• 聚合函数：就我所知，MySQL没有提供空间聚合函数

• K最近邻居：仅PostGIS支持KNN。仅使用索引即可找到最接近任何点的点：无需计算所有点的距离！

• 索引。PostgreSQL允许您在空间索引（即要点/杜松子酒索引）上存储任何数据。例如，您可以将year（或其他非空间数据）和和存储geom在同一索引上。请参阅btree_gin和btree_gist以获取有关如何执行此操作的更多信息。

另外，PostGIS支持大约200多个功能。

简而言之，MySQL并不拥有PostGIS，它知道这一点。PostGIS是一头野兽。只是想解释一下这些东西。

我完全同意第一个答案的所有说法，但是分享我自己的经验-我已经在我国的国家道路管理局（National Roads Administration）上做到了这一点：生产评论家，高流量站点。我建议由MySQL和PostgreSQL / PostGIS共同提供一个Web应用程序。

对于所有“典型”的东西，Web应用程序都可以与基于MySQL的CMS完美配合。对于所有空间任务，同一个Web应用程序-完美无缺地工作；）使用PostgreSQL / PostGIS为基础的自定义开发。第一个组件已经开发出来，并且可以通过普通的MySQL技能轻松维护。第二部分从一开始就涉及更多的研究工作。

您不必在不太熟悉的PostgreSQL / PostGIS中强制执行昂贵的典型事物的完整实现，也不必在MySQL中也不强制对地理空间信息进行次优的实现。让每个玩家在可以打的地方玩。