GIS: PostGIS/PostgreSQL VS MySql VS SQL Server？

小开

我使用过所有这三个数据库，并在它们之间进行了迁移，所以希望我仍然可以为一篇旧文章添加一些内容。十年前，我的任务是将一个大型数据集——4.5亿个空间对象——从 GML 放到一个空间数据库中。我决定试试 MySQL 和 Postgis，当时 SQL Server 没有空间，我们有一个小的启动环境，所以 MySQL 看起来很适合。随后，我参与了 MySQL 的开发，参加了几个会议并发表了演讲，我还积极参与了 MySQL 中与 GIS 兼容的功能的 beta 测试，这些功能最终在5.5版本中发布。随后，我参与了将我们的空间数据迁移到 Postgis 以及将我们的公司数据(带有空间元素)迁移到 SQLServer 的工作。这些是我的发现。

MySQL

1).稳定性问题。在5年的时间里，我们遇到了一些数据库损坏的问题，这些问题只能通过在索引文件上运行 myismachk 来解决，这个过程在4.5亿行表上需要超过24小时的时间。

2).直到最近，只有 MyISAM 表支持空间数据类型。这意味着如果您想要事务支持，那么您就不走运了。InnoDB 表类型现在确实支持空间类型，但是不支持空间类型的索引，因为给定空间数据集的典型大小，索引就没有太大用处了。参见 http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html我参加会议的经验是，空间很大程度上是事后才想到的——我们已经实现了复制、分区等等，但它不适用于空间。编辑: 在即将发布的5.7.5版本中，InnoDB 将最终支持空间列上的索引，这意味着 ACID、外键和空间索引将最终在同一个引擎中可用。

3).与 Postgis 和 SQLServer 的空间功能相比，空间功能非常有限。仍然没有作用于整个几何字段的 ST _ Union 函数，这是我最常运行的查询之一，也就是说，你不能写:

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

这是非常有用的地理信息系统上下文。其中一个几何图形是硬编码的常数几何图形，相比之下有一点局限性。

4)不支持栅格。能够在数据库中进行矢量栅格分析是非常有用的 GIS 功能。

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

6)自从甲骨文收购以来，空间技术确实被搁置了。

总的来说，为了对 MySQL 公平起见，它支持我们的网站，WMS 和一般空间处理了几年，并且很容易建立。不利的一面是，数据损坏是一个问题，由于被迫使用 MyISAM 表，您正在放弃 RDBMS 的许多好处。

Postgis

考虑到 MySQL 存在的问题，我们最终转换成了 Postgis。

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

快速的开发速度——光栅、拓扑、3D 支持就是最近的例子。

3).非常活跃的社区。Postgis irc 频道和邮件列表是极好的资源。Postgis 参考手册也很棒。http://postgis.net/docs/manual-2.0/

在 OSGeo 的保护伞下，与其他应用程序(如 GeoServer 和 GDAL)相处得很好。

存储过程可以用多种语言编写，除了默认的 plpgsql，比如 Python 或 R。

Postgres 是一个非常符合标准的、功能齐全的 RDBMS，旨在与 ANSI 标准保持一致。

6).支持窗口函数和递归查询——不是在 MySQL 中，而是在 SQLServer 中。这使得编写更复杂的空间查询变得更简单。

SQL Server.

我只使用了 SQL Server 2008空间功能，而且该版本的许多烦恼——缺乏对从一个 CRS 到另一个 CRS 转换的支持，需要向空间索引添加自己的参数——现在已经得到解决。

1).由于 SQLServer 中的空间对象基本上是 CLR 对象，因此语法感觉是向后的。您可以编写 geom.STArea () ，而不是 ST _ Area (geom) ，当您将函数链接在一起时，这一点变得更加明显。在函数名中删除下划线只是一个小麻烦。

2).我有一些无效的多边形已经被 SQLServer 接受，并且缺少 ST _ MakeValid 函数可能使这有点痛苦。

3).只有窗户。一般来说，微软的产品(如 ESRI 产品)被设计成能够很好地相互协作，但是并不总是以标准的一致性和互操作性为主要目标。如果你只经营橱窗商店，这不是一个问题。

UPDATE : 在使用了 SQL Server 2012之后，我可以说它已经有了显著的改进。现在有一个很好的几何验证功能，对地理数据类型有很好的支持，包括一个 FULL GLOBE 对象，它允许表示占据一个以上半球的对象，并支持复合曲线与圆形弦，这对于精确和紧凑表示弧(和圆圈)等事情是有用的。从一个 CRS 到另一个 CRS 的坐标转换仍然需要在第三方库中完成，尽管在大多数应用程序中这不是一个显示阻塞。

我还没有使用 SQL Server 和足够大的数据集来与 Postgis/MySQL 进行一对一的比较，但从我所看到的函数运行正确，虽然不像 Postgis 那样功能齐全，但它是对 MySQL 提供的功能的一个巨大改进。

很抱歉回答了这么长的问题，我希望这些年来我所经历的痛苦和快乐可以帮助到某些人。

毫无疑问，这就是为什么。

Postgres 在性能上远远优于 MySQL。服务器具有更强的容错能力，具有开箱即用的负载平衡、缓存和优化工具。
PostGIS 正在成为 GIS 应用程序的标准。
免费的。

最佳答案

如果您有兴趣进行彻底的比较，我建议 “交叉比较 SQL Server 2008 Space，PostgreSQL/PostGIS 1.3-1.4，MySQL 5-6”和/或 “比较 SQL Server 2008 R2、 Oracle 11G R2、 PostgreSQL/PostGIS 1.5空间特性”波士顿地理信息系统。

考虑到你的观点:

我熟悉 DBMS: 在 Windows 上设置 PostGIS 数据库很容易，使用 PgAdmin3管理也很简单
它可以很好地处理 GIS 查询: PostGIS 绝对是三者中最强的，只有 Oracle Space 可以与之媲美，但是如果考虑到它的成本，它将被取消资格

低成本: + 1 for PostGIS for sure

不与 Microsoft. NET Framework 对抗: 您至少应该能够通过 ODBC (参见 Postgres wiki)进行连接

与 R: 兼容不应该是这三者中的任何一个的问题

小开

注意，MySQL 最终添加了适当的 GIS 逻辑。

Http://dev.mysql.com/doc/refman/5.6/en/functions-for-testing-spatial-relations-between-geometric-objects.html

但是在这个阶段我不能评论成本或性能

小开

PostGIS 是最好的，因为它正在成为 GIS 应用程序的标准，而且 PostGIS 是免费的。它的性能远远优于 MySQL

小开

我使用过所有这三个数据库，并在它们之间进行了迁移，所以希望我仍然可以为一篇旧文章添加一些内容。十年前，我的任务是将一个大型数据集——4.5亿个空间对象——从 GML 放到一个空间数据库中。我决定试试 MySQL 和 Postgis，当时 SQL Server 没有空间，我们有一个小的启动环境，所以 MySQL 看起来很适合。随后，我参与了 MySQL 的开发，参加了几个会议并发表了演讲，我还积极参与了 MySQL 中与 GIS 兼容的功能的 beta 测试，这些功能最终在5.5版本中发布。随后，我参与了将我们的空间数据迁移到 Postgis 以及将我们的公司数据(带有空间元素)迁移到 SQLServer 的工作。这些是我的发现。

MySQL

1).稳定性问题。在5年的时间里，我们遇到了一些数据库损坏的问题，这些问题只能通过在索引文件上运行 myismachk 来解决，这个过程在4.5亿行表上需要超过24小时的时间。

2).直到最近，只有 MyISAM 表支持空间数据类型。这意味着如果您想要事务支持，那么您就不走运了。InnoDB 表类型现在确实支持空间类型，但是不支持空间类型的索引，因为给定空间数据集的典型大小，索引就没有太大用处了。参见 http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html我参加会议的经验是，空间很大程度上是事后才想到的——我们已经实现了复制、分区等等，但它不适用于空间。编辑: 在即将发布的5.7.5版本中，InnoDB 将最终支持空间列上的索引，这意味着 ACID、外键和空间索引将最终在同一个引擎中可用。

3).与 Postgis 和 SQLServer 的空间功能相比，空间功能非常有限。仍然没有作用于整个几何字段的 ST _ Union 函数，这是我最常运行的查询之一，也就是说，你不能写:

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

这是非常有用的地理信息系统上下文。其中一个几何图形是硬编码的常数几何图形，相比之下有一点局限性。

4)不支持栅格。能够在数据库中进行矢量栅格分析是非常有用的 GIS 功能。

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

6)自从甲骨文收购以来，空间技术确实被搁置了。

总的来说，为了对 MySQL 公平起见，它支持我们的网站，WMS 和一般空间处理了几年，并且很容易建立。不利的一面是，数据损坏是一个问题，由于被迫使用 MyISAM 表，您正在放弃 RDBMS 的许多好处。

Postgis

考虑到 MySQL 存在的问题，我们最终转换成了 Postgis。

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

快速的开发速度——光栅、拓扑、3D 支持就是最近的例子。

3).非常活跃的社区。Postgis irc 频道和邮件列表是极好的资源。Postgis 参考手册也很棒。http://postgis.net/docs/manual-2.0/

在 OSGeo 的保护伞下，与其他应用程序(如 GeoServer 和 GDAL)相处得很好。

存储过程可以用多种语言编写，除了默认的 plpgsql，比如 Python 或 R。

Postgres 是一个非常符合标准的、功能齐全的 RDBMS，旨在与 ANSI 标准保持一致。

6).支持窗口函数和递归查询——不是在 MySQL 中，而是在 SQLServer 中。这使得编写更复杂的空间查询变得更简单。

SQL Server.

我只使用了 SQL Server 2008空间功能，而且该版本的许多烦恼——缺乏对从一个 CRS 到另一个 CRS 转换的支持，需要向空间索引添加自己的参数——现在已经得到解决。

1).由于 SQLServer 中的空间对象基本上是 CLR 对象，因此语法感觉是向后的。您可以编写 geom.STArea () ，而不是 ST _ Area (geom) ，当您将函数链接在一起时，这一点变得更加明显。在函数名中删除下划线只是一个小麻烦。

2).我有一些无效的多边形已经被 SQLServer 接受，并且缺少 ST _ MakeValid 函数可能使这有点痛苦。

3).只有窗户。一般来说，微软的产品(如 ESRI 产品)被设计成能够很好地相互协作，但是并不总是以标准的一致性和互操作性为主要目标。如果你只经营橱窗商店，这不是一个问题。

UPDATE : 在使用了 SQL Server 2012之后，我可以说它已经有了显著的改进。现在有一个很好的几何验证功能，对地理数据类型有很好的支持，包括一个 FULL GLOBE 对象，它允许表示占据一个以上半球的对象，并支持复合曲线与圆形弦，这对于精确和紧凑表示弧(和圆圈)等事情是有用的。从一个 CRS 到另一个 CRS 的坐标转换仍然需要在第三方库中完成，尽管在大多数应用程序中这不是一个显示阻塞。

我还没有使用 SQL Server 和足够大的数据集来与 Postgis/MySQL 进行一对一的比较，但从我所看到的函数运行正确，虽然不像 Postgis 那样功能齐全，但它是对 MySQL 提供的功能的一个巨大改进。

很抱歉回答了这么长的问题，我希望这些年来我所经历的痛苦和快乐可以帮助到某些人。