GIS:PostGIS/PostgreSQL与MySQL和SQLServer?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (137)

我已经使用Postgres与PostGIS几个月了,我很满意。

我需要分析几百万个地理编码记录,每个记录都有纬度和经度。这些记录包括至少三种不同类型的数据,我将试图查看每一组是否影响到另一组。

对于所有这些数据,哪个数据库最适合底层数据存储?我的愿望是:

  • 我对DBMS很熟悉。我在PostgreSQL方面最薄弱,但我愿意学习其他所有的检查结果。
  • 它可以很好地处理GIS查询。谷歌搜索显示PostgreSQL+PostGIS可能是最强的?至少很多产品似乎都在使用它。MySQL的空间扩展看起来相对较小吗?
  • 低成本。尽管SQLServerExpress 2008 R2中有10 GB的DB限制,但我不确定我是否愿意忍受这个限制和免费版本的其他限制。
  • 与Microsoft.NET Framework不对抗性。由于Connector/NET6.3.4,MySQL可以很好地运行C#和.NET Framework 4程序。它完全支持.NET 4的实体框架。我找不到任何非商业PostgreSQL等值,虽然我不反对为Devart的dotConnect为PostgreSQL专业版支付180美元。
  • 与R.看起来所有这三个都可以使用ODBC与R对话,所以可能不是一个问题。

我已经使用MySQL进行了一些开发,但如果有必要,我可以进行更改。

提问于
用户回答回答于

如果有兴趣进行彻底的比较,我建议你交叉比较SQLServer2008space,PostgreSQL/PostGIS 1.3-1.4,MySQL5-6和/或比较SQLServer 2008R2,Oracle11GR2,PostgreSQL/PostGIS 1.5空间特征地理信息系统。

考虑到你们的观点:

  • 我熟悉DBMS:在Windows上建立PostGIS数据库是容易的,使用PgAdmin 3管理也是直接的
  • 它很好地处理GIS查询:PostGIS绝对是三者中最强的,只有OracleSpace可以与之媲美,但如果考虑到它的成本,它将被取消资格。
  • 低成本:+1用于邮政地理信息系统
  • 不与Microsoft.NET Framework对立:至少应该能够通过ODBC进行连接(见Postgres wiki)
  • 与R兼容:三个人中的任何一个都不会有问题
用户回答回答于

我已经处理了这三个数据库,并在它们之间进行了迁移,所以希望我仍然可以在旧的帖子中添加一些内容。十年前,我的任务是把一个巨大的四亿五千万个空间对象-数据集从gml到一个空间数据库。我决定尝试MySQL和Postgis,当时SQLServer中没有空间,我们有一个小的启动氛围,所以MySQL看起来很适合。我随后参与了mysql,我参加了几次会议/演讲,并大量参与了对mysql中更符合地理信息系统的功能的测试版测试,该测试最终随版本5.5一起发布。随后,我参与了将我们的空间数据迁移到PostGis,并将我们的公司数据(带有空间元素)迁移到SQL Server。这是我的发现。

MySQL

1)。稳定性问题。在过去的5年中,我们遇到了几个数据库损坏问题,这些问题只能通过在索引文件上运行myismachk来解决,而在四亿五千万行表上运行这个进程需要超过24小时。

2)。直到最近,只有MyISAM表支持空间数据类型。这意味着,如果您想要事务支持,你是运气不好。InnoDB表类型现在支持空间类型,但不支持索引,因为给定空间数据集的典型大小,索引并不是非常有用的。见...我去参加会议的经验是,空间是一种事后思考--我们已经实现了复制、分区等,但它不适用于空间。编辑:在即将发布的5.7.5版本InnoDB最终将支持空间列上的索引,这意味着ACID、外键和空间索引最终将在同一个引擎中可用。

3)。与Postgis和SQLServer空间功能相比,空间功能非常有限。仍然没有ST_作用于整个几何域的UNION函数,这是我最常运行的查询之一,即不能编写:

select attribute, ST_Union(geom) from some_table group by some_attribute

在地理信息系统中非常有用。Select ST_Union(geom1, const_geom) from some_table也就是说,其中一个几何图形是硬编码的常量几何图形,与之相比有点限制.

4)。不支持光栅。能够在db内进行矢量光栅分析是非常有用的GIS功能。

5)。不支持从一个空间参考系统转换为另一个空间参考系统。

6)。自甲骨文收购以来,空间已经真正被搁置。

总的来说,对于MySQL来说,它支持我们的网站、WMS和一般的空间处理几年,而且很容易建立。不利的一面是,数据损坏是一个问题,由于被迫使用MyISAM表,你将放弃RDBMS的许多好处。

波斯特吉斯

考虑到我们在MySQL中遇到的问题,我们最终改用PostGis。这次经历的要点是。

1)。极度稳定。5年内没有数据损坏,我们现在在Centos虚拟机上有大约25个Postgres/GIS盒子,在不同的负载下。

2)。快速的发展步伐--光栅,拓扑,3D支持就是最近的例子。

3)。非常活跃的社区。Postgis IRC频道和邮件列表是优秀的资源。“邮政信息系统参考手册”也很出色。http://postgis.net/docs/手册-2.0/

4)。在OSGeo的保护伞下,如Geoserver和GDAL,与其他应用程序一起运行得非常好。

5)。存储过程可以用多种语言编写,除了默认的plpgsql之外,例如Python或R。

5)。Postgres是一个非常符合标准,功能齐全的RDBMS,其目标是保持接近ANSI标准。

6)。对窗口函数和递归查询的支持--不是在MySQL中,而是在SQLServer中。这使得编写更复杂的空间查询变得更干净。

SQLServer。

我只使用了SQLServer 2008空间功能,该版本的许多烦恼--对从一个CRS转换到另一个CRS的支持不足,以及向空间索引中添加你自己的参数的需要--现在已经解决了。

1)。由于SQL Server中的空间对象基本上是CLR对象,因此语法感觉是向后的。而不是ST_面积(Geom)--你可以编写geal.STArea()--当您将函数链接在一起时,这一点就更加明显了。在函数名中删除下划线只是一个小麻烦。

2)。我有许多被SQLServer接受的无效多边形,并且缺少ST_MakeValid函数可以使这有点痛苦。

3)。只有窗户。通常,Microsoft产品(如ESRI产品)的设计目的是很好地相互配合,但并不总是将标准的遵从性和互操作性作为主要目标。如果您正在运行的是仅限窗口商店,这不是一个问题。

更新:在使用了SQLServer 2012之后,我可以说它有了很大的改进。现在有了良好的几何验证功能,对地理数据类型有很好的支持,包括一个完整的全局对象,它允许表示占用多个半球的对象,并支持复合曲线与圆串这对于精确而紧凑地表示弧(和圆)以及其他事物是有用的。从一个CRS转换到另一个CRS的坐标仍然需要在第三个政党库中完成,尽管在大多数应用程序中这并不是一个显示的障碍。

我还没有使用具有足够大数据集的SQL Server来与Postgis/MySQL进行一对一的比较,但是从我所看到的函数的正确行为来看,虽然没有PostGis功能完整,但它是MySQL产品的一个巨大改进。

对于这么长的答案,我很抱歉,我希望这些年来我所遭受的一些痛苦和快乐可能会对某人有所帮助。

扫码关注云+社区

领取腾讯云代金券