EDIT: I have been using Postgres with PostGIS for a few months now, and I am satisfied.
编辑:我已经在PostGIS上使用了几个月的Postgres，我很满意。
I need to analyze a few million geocoded records, each of which will have latitude and longitude. These records include data of at least three different types, and I will be trying to see if each set influences the other.
我需要分析几百万个地理编码记录，每个记录都有经纬度。这些记录包括至少三种不同类型的数据，我将尝试看看每个集合是否影响另一个。
What database is best for the underlying data store for all this data? Here's my desires:
对于所有这些数据，哪个数据库最适合底层数据存储?这是我的愿望:
- I'm familiar with the DBMS. I'm weakest with PostgreSQL, but I am willing to learn if everything else checks out.
- 我对DBMS很熟悉。我在PostgreSQL中是最弱的，但是如果其他一切都顺利的话，我愿意学习。
- It does well with GIS queries. Google searches suggest that PostgreSQL + PostGIS may be the strongest? At least a lot of products seem to use it. MySql's Spatial Extensions seem comparatively minimal?
- 它很适合GIS查询。谷歌搜索表明PostgreSQL + PostGIS可能是最强的?至少很多产品似乎都在使用它。MySql的空间扩展似乎比较小?
- Low cost. Despite the 10GB DB limit in SQL Server Express 2008 R2, I'm not sure I want to live with this and other limitations of the free version.
- 低成本。尽管SQL Server Express 2008 R2中有10GB的DB限制，但我不确定我是否愿意忍受免费版本的这些限制和其他限制。
- Not antagonistic with Microsoft .NET Framework. Thanks to Connector/Net 6.3.4, MySql works well C# and .NET Framework 4 programs. It fully supports .NET 4's Entity Framework. I cannot find any noncommercial PostgreSQL equivalent, although I'm not opposed to paying $180 for Devart's dotConnect for PostgreSQL Professional Edition.
- 不是与微软。net框架对抗。由于连接器/Net 6.3.4, MySql运行良好的c#和。Net框架4程序。它完全支持。net 4的实体框架。我找不到任何与PostgreSQL等价的非商业性PostgreSQL，尽管我并不反对为Devart的dotConnect提供PostgreSQL专业版支付180美元。
- Compatible with R. It appears all 3 of these can talk with R using ODBC, so may not be an issue.
- 与R兼容，这三个都可以使用ODBC与R通信，所以可能不是问题。
I've already done some development using MySql, but I can change if necessary.
我已经用MySql做了一些开发，但是如果需要的话我可以修改。
5 个解决方案
#1
47
If you are interested in a thorough comparison, I recommend "Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6" and/or "Compare SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5 Spatial Features" by Boston GIS.
如果您对一个完整的比较感兴趣，我推荐“Cross Compare SQL Server 2008空间，PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6”和/或“比较SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5空间特性”。
Considering your points:
考虑你的点:
- I'm familiar with the DBMS: setting up a PostGIS database on Windows is easy, using PgAdmin3 management is straight-forward too
- 我熟悉DBMS:在Windows上建立PostGIS数据库很容易，使用PgAdmin3管理也很直接
- It does well with GIS queries: PostGIS is definitely strongest of the three, only Oracle Spatial would be comparable but is disqualified if you consider it's costs
- 它在GIS查询方面做得很好:PostGIS绝对是这三种查询中最强的，只有Oracle Spatial可以进行比较，但是如果考虑到它的成本，它是不合格的
- Low cost: +1 for PostGIS for sure
- 低成本:+1的PostGIS肯定。
- Not antagonistic with Microsoft .NET Framework: You should at least be able to connect via ODBC (see Postgres wiki)
- 不要与Microsoft .NET框架对立:您至少应该能够通过ODBC连接(参见Postgres wiki)。
- Compatible with R: shouldn't be a problem with any of the three
- 与R兼容:这三个都不应该有问题
#2
55
I have worked with all three databases and done migrations between them, so hopefully I can still add something to an old post. Ten years ago I was tasked with putting a largish -- 450 million spatial objects -- dataset from GML to a spatial database. I decided to try out MySQL and Postgis, at the time there was no spatial in SQL Server and we had a small startup atmosphere, so MySQL seemed a good fit. I subsequently was involved in MySQL, I attended/spoke at a couple of conferences and was heavily involved in the beta testing of the more GIS-compliant functions in MySQL that was finally released with version 5.5. I have subsequently been involved with migrating our spatial data to Postgis and our corporate data (with spatial elements) to SQL Server. These are my findings.
我已经使用了这三个数据库，并在它们之间进行了迁移，所以我希望我仍然可以为旧的帖子添加一些内容。十年前，我的任务是把一个较大的——4.5亿个空间对象——数据集从GML放到一个空间数据库中。我决定尝试使用MySQL和Postgis，当时SQL Server中没有空间，我们有一个小的启动环境，所以MySQL看起来很适合。后来我加入了MySQL，参加了几次会议，并参与了MySQL中更兼容gis的功能的beta测试，最终在版本5.5中发布。随后，我参与了将空间数据迁移到Postgis，并将公司数据(带有空间元素)迁移到SQL Server。这些是我的调查结果。
MySQL
MySQL
1). Stability issues. Over the course of 5 years, we had several database corruptions issues, which could only be fixed by running myismachk on the index file, a process than can take well over 24 hours on a 450 million row table.
1)。稳定性问题。在5年的时间里，我们遇到了几个数据库问题，这些问题只能通过在索引文件上运行myismachk来解决，在4.5亿行表上运行myismachk需要24小时以上的时间。
2). Until recently only MyISAM tables supported the spatial data type. This means if you want transaction support you are out of luck. InnoDB table type does now support spatial types, but not indexes on them, which given the typical sizes of spatial data sets, isn't terribly useful. See http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html My experience from going to conferences was that spatial was very much an afterthought -- we've implemented replication, partitioning, etc, but it doesn't work with spatial. EDIT: In the upcoming 5.7.5 release InnoDB will finally support indexes on spatial columns, meaning that ACID, foreign keys and spatial indexes will finally be available in the same engine.
2).直到最近，只有MyISAM表支持空间数据类型。这意味着如果你想要事务支持，那你就不走运了。InnoDB表类型现在支持空间类型，但不支持它们的索引，因为它们具有典型的空间数据集大小，这并不是非常有用。参见http://dev.mysql.com/doc/refman/5.0/en/innodb- limittions.html我参加会议的经验是，空间在很大程度上是事后才想到的——我们已经实现了复制、分区等等，但是它不能用于空间。编辑:在即将发布的5.7.5版本中，InnoDB将最终支持空间列上的索引，这意味着ACID、外键和空间索引将最终在同一个引擎中可用。
3). The spatial functionality is extremely limited compared to both Postgis and SQL Server spatial. There is still no ST_Union function that acts on an entire geometry field, one of the queries I run most often, ie, you can't write:
3).与Postgis和SQL Server spatial相比，空间功能非常有限。仍然没有ST_Union函数作用于整个几何字段，这是我最常运行的查询之一，也就是说，您不能写:
select attribute, ST_Union(geom) from some_table group by some_attribute
which is very useful in a GIS context. Select ST_Union(geom1, const_geom) from some_table, ie, one of the geometries is a hard-coded constant geometry is a bit limiting in comparison.
这在GIS环境中非常有用。从some_table中选择ST_Union(geom1, const_geom)，也就是说，其中一个几何图形是硬编码的常数几何，相比之下，这个几何图形有点限制。
4). No support for rasters. Being able to do combined vector-raster analysis within a db is very useful GIS functionality.
4).不支持光栅。能够在db中进行矢量栅格分析是非常有用的GIS功能。
5). No support for conversion from one spatial reference system to another.
5).不支持从一个空间参考系统转换到另一个空间参考系统。
6). Since acquisistion by Oracle, spatial has really been put on hold.
6).自从Oracle收购以后，spatial确实被搁置了。
Overall, to be fair to MySQL it supported our website, WMS and general spatial processing for several years, and was easy to set up. On the downside, data corruption was an issue, and by being forced to use MyISAM tables you are giving up a lot of the benefits of an RDBMS.
总的来说，公平地说，它支持我们的网站，WMS和一般的空间处理好几年，并且很容易建立。缺点是，数据损坏是一个问题，由于*使用MyISAM表，您将放弃RDBMS的许多好处。
Postgis
Postgis
Given the issues we had with MySQL, we ultimately converted to Postgis. The key points of this experience have been.
考虑到MySQL存在的问题，我们最终转换为Postgis。这段经历的关键是。
1). Extreme stability. No data corruption in 5 years and we now have around 25 Postgres/GIS boxes on centos virtual machines, under varying degrees of load.
1)。极端稳定。5年内没有数据损坏，我们现在在centos虚拟机上有大约25个Postgres/GIS盒子，负载不同程度。
2). Rapid pace of development -- raster, topology, 3D support being recent examples of this.
2)开发速度快——光栅、拓扑、3D支持是最近的例子。
3). Very active community. The Postgis irc channel and mailing list are excellent resources. The Postgis reference manual is also excellent. http://postgis.net/docs/manual-2.0/
3),非常活跃的社区。邮政gis irc频道和邮件列表是极好的资源。Postgis参考手册也很优秀。http://postgis.net/docs/manual - 2.0 /
4). Plays very well with other applications, under the OSGeo umbrella, such as GeoServer and GDAL.
4).在OSGeo保护伞下，与GeoServer、GDAL等其他应用程序配合良好。
5). Stored procedures can be written in many languages, apart from the default plpgsql, such as Python or R.
5).存储过程可以用多种语言编写，除了默认的plpgsql，如Python或R。
5). Postgres is a very standards compliant, fully featured RDBMS, which aims to stay close to the ANSI standards.
5). Postgres是一个非常符合标准的、功能齐全的RDBMS，旨在保持接近ANSI标准。
6). Support for window functions and recursive queries -- not in MySQL, but in SQL Server. This has made writing more complex spatial queries cleaner.
6).支持窗口函数和递归查询——不是在MySQL中，而是在SQL Server中。这使得编写更复杂的空间查询变得更加清晰。
SQL Server.
SQL服务器。
I have only used SQL Server 2008 spatial functionality, and many of the annoyances of that release -- lack of support for conversions from one CRS to another, the need to add your own parameters to spatial indexes -- have now been resolved.
我只使用了SQL Server 2008的空间功能，而该版本的许多缺点——不支持从一个CRS转换到另一个CRS，需要向空间索引添加自己的参数——现在已经得到解决。
1). As spatial objects in SQL Server are basically CLR objects, the syntax feels backwards. Instead of ST_Area(geom) you write geom.STArea() and this becomes even more obvious when you chain functions together. The dropping of the underscore in function names is merely a minor annoyance.
1).由于SQL Server中的空间对象基本上都是CLR对象，所以语法是向后的。与ST_Area(geom)不同，您编写的是geom.STArea()，当您将函数链接在一起时，这一点变得更加明显。函数名中下划线的删除只是一个小麻烦。
2). I have had a number of invalid polygons that have been accepted by SQL Server, and the lack of a ST_MakeValid function can make this a bit painful.
2).我有过一些被SQL Server接受的无效多边形，而缺少ST_MakeValid函数可能会让我有点痛苦。
3). Windows only. In general, Microsoft products (like ESRI ones) are designed to work very well with each other, but don't always have standard's compliance and interoperability as primary objectives. If you are running a windows only shop, this is not an issue.
3)。Windows。一般来说，Microsoft产品(如ESRI产品)被设计成能够很好地相互协作，但并不总是将标准的遵从性和互操作性作为主要目标。如果你只运行windows商店，这不是问题。
UPDATE: having played a bit with SQL Server 2012, I can say that it has been improved significantly. There is now a good geometry validation function, there is good support for the Geography data type, including a FULL GLOBE object, which allows representing objects that occupy more than one hemisphere and support for Compound Curves and Circular Strings which is useful for accurate and compact representations of arcs (and circles) among other things. Transforming coordinates from one CRS to another still needs to be done in 3rd party libraries, though this is not a show stopper in most applications.
更新:在使用了SQL Server 2012之后，我可以说它得到了显著的改进。现在有一个很好的几何验证功能,有很好的对地理数据类型的支持,包括一个完整的全球对象,它允许代表对象占用多于一个半球和支持复合曲线和圆弦是准确和有用的紧凑表示圆弧(圆)。从一个CRS转换到另一个CRS的坐标仍然需要在第三方库中完成，尽管在大多数应用程序中这并不是一个显示限制。
I haven't used SQL Server with large enough datasets to compare one on one with Postgis/MySQL, but from what I have seen the functions behave correctly, and while not quite as fully featured as Postgis, it is a huge improvement on MySQL's offerings.
我还没有使用足够大的数据集来比较一个和Postgis/MySQL的数据集，但是从我所看到的函数的正常运行情况来看，虽然没有像Postgis那样充分的功能，但它对MySQL的服务是一个巨大的改进。
Sorry for such a long answer, I hope some of the pain and joy I have suffered over the years might be of help to someone.
很抱歉这么长时间的回答，我希望这些年来我所遭受的一些痛苦和欢乐能对某些人有所帮助。
#3
16
PostGis definitely. Here's why.
PostGis肯定。这是为什么。
- Postgres is far superior to MySQL in performance. Server is more fault tolerant, has out of the box tools for load-balancing, caching and optimization.
- Postgres在性能上远远优于MySQL。服务器具有更强的容错能力，具有开箱即用的负载平衡、缓存和优化工具。
- PostGIS is becoming a standard in GIS apps.
- PostGIS正在成为GIS应用中的一个标准。
- It's free.
- 这是免费的。
#4
0
Just an note that MySQL has finally added in proper GIS logic.
请注意，MySQL最终添加了正确的GIS逻辑。
http://dev.mysql.com/doc/refman/5.6/en/functions-for-testing-spatial-relations-between-geometric-objects.html
But I can't comment on cost or performance at this stage
但现阶段我无法对成本或业绩发表评论
#5
0
PostGIS is best because it is becoming a standard in GIS applications these days and PostGIS is free. It is far superior to MySQL in performance
PostGIS是最好的，因为它正在成为GIS应用的标准，而PostGIS是免费的。它在性能上远远优于MySQL
#1
47
If you are interested in a thorough comparison, I recommend "Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6" and/or "Compare SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5 Spatial Features" by Boston GIS.
如果您对一个完整的比较感兴趣，我推荐“Cross Compare SQL Server 2008空间，PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6”和/或“比较SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5空间特性”。
Considering your points:
考虑你的点:
- I'm familiar with the DBMS: setting up a PostGIS database on Windows is easy, using PgAdmin3 management is straight-forward too
- 我熟悉DBMS:在Windows上建立PostGIS数据库很容易，使用PgAdmin3管理也很直接
- It does well with GIS queries: PostGIS is definitely strongest of the three, only Oracle Spatial would be comparable but is disqualified if you consider it's costs
- 它在GIS查询方面做得很好:PostGIS绝对是这三种查询中最强的，只有Oracle Spatial可以进行比较，但是如果考虑到它的成本，它是不合格的
- Low cost: +1 for PostGIS for sure
- 低成本:+1的PostGIS肯定。
- Not antagonistic with Microsoft .NET Framework: You should at least be able to connect via ODBC (see Postgres wiki)
- 不要与Microsoft .NET框架对立:您至少应该能够通过ODBC连接(参见Postgres wiki)。
- Compatible with R: shouldn't be a problem with any of the three
- 与R兼容:这三个都不应该有问题
#2
55
I have worked with all three databases and done migrations between them, so hopefully I can still add something to an old post. Ten years ago I was tasked with putting a largish -- 450 million spatial objects -- dataset from GML to a spatial database. I decided to try out MySQL and Postgis, at the time there was no spatial in SQL Server and we had a small startup atmosphere, so MySQL seemed a good fit. I subsequently was involved in MySQL, I attended/spoke at a couple of conferences and was heavily involved in the beta testing of the more GIS-compliant functions in MySQL that was finally released with version 5.5. I have subsequently been involved with migrating our spatial data to Postgis and our corporate data (with spatial elements) to SQL Server. These are my findings.
我已经使用了这三个数据库，并在它们之间进行了迁移，所以我希望我仍然可以为旧的帖子添加一些内容。十年前，我的任务是把一个较大的——4.5亿个空间对象——数据集从GML放到一个空间数据库中。我决定尝试使用MySQL和Postgis，当时SQL Server中没有空间，我们有一个小的启动环境，所以MySQL看起来很适合。后来我加入了MySQL，参加了几次会议，并参与了MySQL中更兼容gis的功能的beta测试，最终在版本5.5中发布。随后，我参与了将空间数据迁移到Postgis，并将公司数据(带有空间元素)迁移到SQL Server。这些是我的调查结果。
MySQL
MySQL
1). Stability issues. Over the course of 5 years, we had several database corruptions issues, which could only be fixed by running myismachk on the index file, a process than can take well over 24 hours on a 450 million row table.
1)。稳定性问题。在5年的时间里，我们遇到了几个数据库问题，这些问题只能通过在索引文件上运行myismachk来解决，在4.5亿行表上运行myismachk需要24小时以上的时间。
2). Until recently only MyISAM tables supported the spatial data type. This means if you want transaction support you are out of luck. InnoDB table type does now support spatial types, but not indexes on them, which given the typical sizes of spatial data sets, isn't terribly useful. See http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html My experience from going to conferences was that spatial was very much an afterthought -- we've implemented replication, partitioning, etc, but it doesn't work with spatial. EDIT: In the upcoming 5.7.5 release InnoDB will finally support indexes on spatial columns, meaning that ACID, foreign keys and spatial indexes will finally be available in the same engine.
2).直到最近，只有MyISAM表支持空间数据类型。这意味着如果你想要事务支持，那你就不走运了。InnoDB表类型现在支持空间类型，但不支持它们的索引，因为它们具有典型的空间数据集大小，这并不是非常有用。参见http://dev.mysql.com/doc/refman/5.0/en/innodb- limittions.html我参加会议的经验是，空间在很大程度上是事后才想到的——我们已经实现了复制、分区等等，但是它不能用于空间。编辑:在即将发布的5.7.5版本中，InnoDB将最终支持空间列上的索引，这意味着ACID、外键和空间索引将最终在同一个引擎中可用。
3). The spatial functionality is extremely limited compared to both Postgis and SQL Server spatial. There is still no ST_Union function that acts on an entire geometry field, one of the queries I run most often, ie, you can't write:
3).与Postgis和SQL Server spatial相比，空间功能非常有限。仍然没有ST_Union函数作用于整个几何字段，这是我最常运行的查询之一，也就是说，您不能写:
select attribute, ST_Union(geom) from some_table group by some_attribute
which is very useful in a GIS context. Select ST_Union(geom1, const_geom) from some_table, ie, one of the geometries is a hard-coded constant geometry is a bit limiting in comparison.
这在GIS环境中非常有用。从some_table中选择ST_Union(geom1, const_geom)，也就是说，其中一个几何图形是硬编码的常数几何，相比之下，这个几何图形有点限制。
4). No support for rasters. Being able to do combined vector-raster analysis within a db is very useful GIS functionality.
4).不支持光栅。能够在db中进行矢量栅格分析是非常有用的GIS功能。
5). No support for conversion from one spatial reference system to another.
5).不支持从一个空间参考系统转换到另一个空间参考系统。
6). Since acquisistion by Oracle, spatial has really been put on hold.
6).自从Oracle收购以后，spatial确实被搁置了。
Overall, to be fair to MySQL it supported our website, WMS and general spatial processing for several years, and was easy to set up. On the downside, data corruption was an issue, and by being forced to use MyISAM tables you are giving up a lot of the benefits of an RDBMS.
总的来说，公平地说，它支持我们的网站，WMS和一般的空间处理好几年，并且很容易建立。缺点是，数据损坏是一个问题，由于*使用MyISAM表，您将放弃RDBMS的许多好处。
Postgis
Postgis
Given the issues we had with MySQL, we ultimately converted to Postgis. The key points of this experience have been.
考虑到MySQL存在的问题，我们最终转换为Postgis。这段经历的关键是。
1). Extreme stability. No data corruption in 5 years and we now have around 25 Postgres/GIS boxes on centos virtual machines, under varying degrees of load.
1)。极端稳定。5年内没有数据损坏，我们现在在centos虚拟机上有大约25个Postgres/GIS盒子，负载不同程度。
2). Rapid pace of development -- raster, topology, 3D support being recent examples of this.
2)开发速度快——光栅、拓扑、3D支持是最近的例子。
3). Very active community. The Postgis irc channel and mailing list are excellent resources. The Postgis reference manual is also excellent. http://postgis.net/docs/manual-2.0/
3),非常活跃的社区。邮政gis irc频道和邮件列表是极好的资源。Postgis参考手册也很优秀。http://postgis.net/docs/manual - 2.0 /
4). Plays very well with other applications, under the OSGeo umbrella, such as GeoServer and GDAL.
4).在OSGeo保护伞下，与GeoServer、GDAL等其他应用程序配合良好。
5). Stored procedures can be written in many languages, apart from the default plpgsql, such as Python or R.
5).存储过程可以用多种语言编写，除了默认的plpgsql，如Python或R。
5). Postgres is a very standards compliant, fully featured RDBMS, which aims to stay close to the ANSI standards.
5). Postgres是一个非常符合标准的、功能齐全的RDBMS，旨在保持接近ANSI标准。
6). Support for window functions and recursive queries -- not in MySQL, but in SQL Server. This has made writing more complex spatial queries cleaner.
6).支持窗口函数和递归查询——不是在MySQL中，而是在SQL Server中。这使得编写更复杂的空间查询变得更加清晰。
SQL Server.
SQL服务器。
I have only used SQL Server 2008 spatial functionality, and many of the annoyances of that release -- lack of support for conversions from one CRS to another, the need to add your own parameters to spatial indexes -- have now been resolved.
我只使用了SQL Server 2008的空间功能，而该版本的许多缺点——不支持从一个CRS转换到另一个CRS，需要向空间索引添加自己的参数——现在已经得到解决。
1). As spatial objects in SQL Server are basically CLR objects, the syntax feels backwards. Instead of ST_Area(geom) you write geom.STArea() and this becomes even more obvious when you chain functions together. The dropping of the underscore in function names is merely a minor annoyance.
1).由于SQL Server中的空间对象基本上都是CLR对象，所以语法是向后的。与ST_Area(geom)不同，您编写的是geom.STArea()，当您将函数链接在一起时，这一点变得更加明显。函数名中下划线的删除只是一个小麻烦。
2). I have had a number of invalid polygons that have been accepted by SQL Server, and the lack of a ST_MakeValid function can make this a bit painful.
2).我有过一些被SQL Server接受的无效多边形，而缺少ST_MakeValid函数可能会让我有点痛苦。
3). Windows only. In general, Microsoft products (like ESRI ones) are designed to work very well with each other, but don't always have standard's compliance and interoperability as primary objectives. If you are running a windows only shop, this is not an issue.
3)。Windows。一般来说，Microsoft产品(如ESRI产品)被设计成能够很好地相互协作，但并不总是将标准的遵从性和互操作性作为主要目标。如果你只运行windows商店，这不是问题。
UPDATE: having played a bit with SQL Server 2012, I can say that it has been improved significantly. There is now a good geometry validation function, there is good support for the Geography data type, including a FULL GLOBE object, which allows representing objects that occupy more than one hemisphere and support for Compound Curves and Circular Strings which is useful for accurate and compact representations of arcs (and circles) among other things. Transforming coordinates from one CRS to another still needs to be done in 3rd party libraries, though this is not a show stopper in most applications.
更新:在使用了SQL Server 2012之后，我可以说它得到了显著的改进。现在有一个很好的几何验证功能,有很好的对地理数据类型的支持,包括一个完整的全球对象,它允许代表对象占用多于一个半球和支持复合曲线和圆弦是准确和有用的紧凑表示圆弧(圆)。从一个CRS转换到另一个CRS的坐标仍然需要在第三方库中完成，尽管在大多数应用程序中这并不是一个显示限制。
I haven't used SQL Server with large enough datasets to compare one on one with Postgis/MySQL, but from what I have seen the functions behave correctly, and while not quite as fully featured as Postgis, it is a huge improvement on MySQL's offerings.
我还没有使用足够大的数据集来比较一个和Postgis/MySQL的数据集，但是从我所看到的函数的正常运行情况来看，虽然没有像Postgis那样充分的功能，但它对MySQL的服务是一个巨大的改进。
Sorry for such a long answer, I hope some of the pain and joy I have suffered over the years might be of help to someone.
很抱歉这么长时间的回答，我希望这些年来我所遭受的一些痛苦和欢乐能对某些人有所帮助。
#3
16
PostGis definitely. Here's why.
PostGis肯定。这是为什么。
- Postgres is far superior to MySQL in performance. Server is more fault tolerant, has out of the box tools for load-balancing, caching and optimization.
- Postgres在性能上远远优于MySQL。服务器具有更强的容错能力，具有开箱即用的负载平衡、缓存和优化工具。
- PostGIS is becoming a standard in GIS apps.
- PostGIS正在成为GIS应用中的一个标准。
- It's free.
- 这是免费的。
#4
0
Just an note that MySQL has finally added in proper GIS logic.
请注意，MySQL最终添加了正确的GIS逻辑。
http://dev.mysql.com/doc/refman/5.6/en/functions-for-testing-spatial-relations-between-geometric-objects.html
But I can't comment on cost or performance at this stage
但现阶段我无法对成本或业绩发表评论
#5
0
PostGIS is best because it is becoming a standard in GIS applications these days and PostGIS is free. It is far superior to MySQL in performance
PostGIS是最好的，因为它正在成为GIS应用的标准，而PostGIS是免费的。它在性能上远远优于MySQL