Eu trabalhei com todos os três bancos de dados e fiz migrações entre eles, então espero que ainda possa adicionar algo a um post antigo. Dez anos atrás, fui encarregado de colocar um grande - 450 milhões de objetos espaciais - conjunto de dados do GML para um banco de dados espacial. Decidi experimentar o MySQL e o Postgis, na época não havia espaço no SQL Server e tínhamos uma pequena atmosfera de inicialização, então o MySQL parecia uma boa opção. Posteriormente, estive envolvido no MySQL, participei/falei em algumas conferências e estive fortemente envolvido no teste beta das funções mais compatíveis com GIS no MySQL que foi finalmente lançada com a versão 5.5. Posteriormente, estive envolvido na migração de nossos dados espaciais para Postgis e nossos dados corporativos (com elementos espaciais) para SQL Server. Estas são as minhas descobertas.
MySQL
1). Problemas de estabilidade. Ao longo de 5 anos, tivemos vários problemas de corrupção de banco de dados, que só poderiam ser corrigidos executando myismachk no arquivo de índice, um processo que pode levar mais de 24 horas em uma tabela de 450 milhões de linhas.
2). Até recentemente, apenas as tabelas MyISAM suportavam o tipo de dados espaciais. Isso significa que, se você deseja suporte a transações, está sem sorte. O tipo de tabela InnoDB agora oferece suporte a tipos espaciais, mas não a índices neles, o que, devido aos tamanhos típicos de conjuntos de dados espaciais, não é muito útil. Veja http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Minha experiência de ir a conferências foi que espacial foi uma reflexão tardia -- implementamos replicação, particionamento, etc, mas não funciona com espacial.EDIT:Na próxima versão 5.7.5, o InnoDB finalmente suportará índices em colunas espaciais, significando que ACID, chaves estrangeiras e índices espaciais estarão finalmente disponíveis no mesmo mecanismo.
3). A funcionalidade espacial é extremamente limitada em comparação com o Postgis e o SQL Server espacial. Ainda não existe uma função ST_Union que atue em um campo de geometria inteiro, uma das consultas que executo com mais frequência, ou seja, não se pode escrever:
select attribute, ST_Union(geom) from some_table group by some_attribute
o que é muito útil em um contexto GIS.
Select ST_Union(geom1, const_geom) from some_table , ou seja, uma das geometrias é uma geometria constante codificada, sendo um pouco limitante em comparação. 4). Não há suporte para rasters. Ser capaz de fazer análises combinadas de vetor-raster dentro de um banco de dados é uma funcionalidade GIS muito útil.
5). Não há suporte para conversão de um sistema de referência espacial para outro.
6). Desde a aquisição pela Oracle, o espaço foi realmente suspenso.
No geral, para ser justo com o MySQL, ele suportou nosso site, WMS e processamento espacial geral por vários anos e foi fácil de configurar. No lado negativo, a corrupção de dados era um problema e, ao ser forçado a usar tabelas MyISAM, você está abrindo mão de muitos benefícios de um RDBMS.
Postgis
Dados os problemas que tivemos com o MySQL, acabamos convertendo para o Postgis. Os pontos-chave desta experiência foram.
1). Estabilidade extrema. Sem corrupção de dados em 5 anos e agora temos cerca de 25 caixas Postgres/GIS em máquinas virtuais centos, sob vários graus de carga.
2). Rápido ritmo de desenvolvimento - raster, topologia, suporte 3D são exemplos recentes disso.
3). Comunidade muito ativa. O canal do Postgis irc e a lista de discussão são excelentes recursos. O manual de referência do Postgis também é excelente. http://postgis.net/docs/manual-2.0/
4). Joga muito bem com outros aplicativos, sob o guarda-chuva OSGeo, como GeoServer e GDAL.
5). Os procedimentos armazenados podem ser escritos em muitas linguagens, além do plpgsql padrão, como Python ou R.
5). O Postgres é um RDBMS muito compatível com os padrões e com todos os recursos, que visa permanecer próximo aos padrões ANSI.
6). Suporte para funções de janela e consultas recursivas -- não no MySQL, mas no SQL Server. Isso tornou a escrita de consultas espaciais mais complexas mais limpa.
SQL Server.
Eu usei apenas a funcionalidade espacial do SQL Server 2008 e muitos dos aborrecimentos dessa versão - falta de suporte para conversões de um CRS para outro, a necessidade de adicionar seus próprios parâmetros aos índices espaciais - foram resolvidos.
1). Como os objetos espaciais no SQL Server são basicamente objetos CLR, a sintaxe parece invertida. Em vez de ST_Area(geom) você escreve geom.STArea() e isso se torna ainda mais óbvio quando você encadeia funções juntas. A eliminação do sublinhado em nomes de funções é apenas um pequeno aborrecimento.
2). Eu tive vários polígonos inválidos que foram aceitos pelo SQL Server, e a falta de uma função ST_MakeValid pode tornar isso um pouco doloroso.
3). Apenas Windows. Em geral, os produtos da Microsoft (como os da ESRI) são projetados para funcionar muito bem uns com os outros, mas nem sempre têm a conformidade e a interoperabilidade dos padrões como objetivos principais. Se você estiver executando uma loja apenas de janelas, isso não é um problema.
ATUALIZAÇÃO :tendo brincado um pouco com o SQL Server 2012, posso dizer que melhorou significativamente. Existe agora uma boa função de validação de geometria, há um bom suporte para o tipo de dados Geography, incluindo um objeto FULL GLOBE, que permite representar objetos que ocupam mais de um hemisfério e suporte para Compound Curves e Circular Strings que é útil para representações de arcos (e círculos) entre outras coisas. A transformação de coordenadas de um CRS para outro ainda precisa ser feita em bibliotecas de terceiros, embora isso não seja um impedimento na maioria dos aplicativos.
Eu não usei o SQL Server com conjuntos de dados grandes o suficiente para comparar um a um com o Postgis/MySQL, mas pelo que vi as funções se comportam corretamente e, embora não sejam tão completos quanto o Postgis, é uma grande melhoria nas ofertas do MySQL .
Desculpe por uma resposta tão longa, espero que um pouco da dor e da alegria que sofri ao longo dos anos possa ajudar alguém.
