Trabajé con las tres bases de datos y realicé migraciones entre ellas, así que espero poder agregar algo a una publicación anterior. Hace diez años, me encargaron colocar un conjunto de datos más grande (450 millones de objetos espaciales) de GML en una base de datos espacial. Decidí probar MySQL y Postgis, en ese momento no había espacial en SQL Server y teníamos una pequeña atmósfera de inicio, por lo que MySQL parecía una buena opción. Posteriormente estuve involucrado en MySQL, asistí/hablé en un par de conferencias y estuve muy involucrado en la prueba beta de las funciones más compatibles con GIS en MySQL que finalmente se lanzó con la versión 5.5. Posteriormente, participé en la migración de nuestros datos espaciales a Postgis y nuestros datos corporativos (con elementos espaciales) a SQL Server. Estos son mis hallazgos.
MySQL
1). Problemas de estabilidad. En el transcurso de 5 años, tuvimos varios problemas de corrupción de bases de datos, que solo podían solucionarse ejecutando myismachk en el archivo de índice, un proceso que puede demorar más de 24 horas en una tabla de 450 millones de filas.
2). Hasta hace poco, solo las tablas MyISAM admitían el tipo de datos espaciales. Esto significa que si desea soporte de transacciones, no tiene suerte. El tipo de tabla de InnoDB ahora admite tipos espaciales, pero no índices en ellos, lo que, dados los tamaños típicos de los conjuntos de datos espaciales, no es muy útil. Consulte http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html. Mi experiencia al asistir a conferencias fue que lo espacial fue una ocurrencia tardía:implementamos la replicación, la partición, etc. pero no funciona con espacial. EDITAR:en la próxima versión 5.7.5, InnoDB finalmente admitirá índices en columnas espaciales, lo que significa que ACID, claves foráneas e índices espaciales finalmente estarán disponibles en el mismo motor.
3). La funcionalidad espacial es extremadamente limitada en comparación con Postgis y SQL Server. Todavía no hay una función ST_Union que actúe en un campo de geometría completo, una de las consultas que ejecuto con más frecuencia, es decir, no puede escribir:
select attribute, ST_Union(geom) from some_table group by some_attribute
lo cual es muy útil en un contexto GIS. Select ST_Union(geom1, const_geom) from some_table , es decir, una de las geometrías es una geometría constante codificada de forma rígida es un poco limitante en comparación.
4). No hay soporte para rásteres. Ser capaz de hacer un análisis combinado de vector-ráster dentro de una base de datos es una funcionalidad GIS muy útil.
5). No se admite la conversión de un sistema de referencia espacial a otro.
6). Desde la adquisición por parte de Oracle, la tecnología espacial ha quedado realmente en suspenso.
En general, para ser justos con MySQL, admitió nuestro sitio web, WMS y procesamiento espacial general durante varios años, y fue fácil de configurar. En el lado negativo, la corrupción de datos fue un problema y, al verse obligado a usar tablas MyISAM, está renunciando a muchos de los beneficios de un RDBMS.
Postgis
Dados los problemas que tuvimos con MySQL, finalmente nos convertimos a Postgis. Los puntos clave de esta experiencia han sido.
1). Estabilidad extrema. Sin corrupción de datos en 5 años y ahora tenemos alrededor de 25 cajas de Postgres/GIS en máquinas virtuales centos, con diversos grados de carga.
2). Rápido ritmo de desarrollo:ráster, topología, compatibilidad con 3D son ejemplos recientes de esto.
3). Comunidad muy activa. El canal IRC de Postgis y la lista de correo son recursos excelentes. El manual de referencia de Postgis también es excelente. http://postgis.net/docs/manual-2.0/
4). Juega muy bien con otras aplicaciones, bajo el paraguas de OSGeo, como GeoServer y GDAL.
5). Los procedimientos almacenados se pueden escribir en muchos idiomas, además del plpgsql predeterminado, como Python o R.
5). Postgres es un RDBMS con todas las funciones y muy compatible con los estándares, cuyo objetivo es mantenerse cerca de los estándares ANSI.
6). Compatibilidad con funciones de ventana y consultas recursivas, no en MySQL, sino en SQL Server. Esto ha hecho que la escritura de consultas espaciales más complejas sea más limpia.
Servidor SQL.
Solo he usado la funcionalidad espacial de SQL Server 2008, y muchas de las molestias de esa versión (falta de soporte para conversiones de un CRS a otro, la necesidad de agregar sus propios parámetros a los índices espaciales) ahora se han resuelto.
1). Como los objetos espaciales en SQL Server son básicamente objetos CLR, la sintaxis se siente al revés. En lugar de ST_Area(geom), escribe geom.STArea() y esto se vuelve aún más obvio cuando encadena funciones. La eliminación del guión bajo en los nombres de las funciones es simplemente una molestia menor.
2). He tenido varios polígonos no válidos que han sido aceptados por SQL Server, y la falta de una función ST_MakeValid puede hacer que esto sea un poco doloroso.
3). Solo ventanas. En general, los productos de Microsoft (como los de ESRI) están diseñados para funcionar muy bien entre sí, pero no siempre tienen como objetivos principales el cumplimiento de los estándares y la interoperabilidad. Si está ejecutando una tienda solo de Windows, esto no es un problema.
ACTUALIZAR :después de haber jugado un poco con SQL Server 2012, puedo decir que se ha mejorado significativamente. Ahora hay una buena función de validación de geometría, hay un buen soporte para el tipo de datos de Geografía, incluyendo un objeto GLOBO COMPLETO, que permite representar objetos que ocupan más de un hemisferio y soporte para Curvas Compuestas y Cadenas Circulares, lo cual es útil para obtener datos precisos y compactos. representaciones de arcos (y círculos) entre otras cosas. La transformación de las coordenadas de un CRS a otro aún debe realizarse en bibliotecas de terceros, aunque esto no es un problema en la mayoría de las aplicaciones.
No he usado SQL Server con conjuntos de datos lo suficientemente grandes como para comparar uno a uno con Postgis/MySQL, pero por lo que he visto, las funciones se comportan correctamente y, aunque no tienen tantas funciones como Postgis, es una gran mejora en las ofertas de MySQL. .
Perdón por una respuesta tan larga, espero que algo del dolor y la alegría que he sufrido a lo largo de los años pueda ser de ayuda para alguien.
