PostgreSQL vs. MySQL: comparação de recursos espaciais

Não posso falar sobre vantagens/desvantagens em relação ao MySQL, mas o código PostGIS é amplamente considerado como um dos melhores (em termos de velocidade/funcionalidade) e mais maduro (em termos de teste/exposição ao mundo real ) acessível.

A título de exemplo, houve uma palestra no PGEast 2010 de algumas pessoas da FAA sobre a conversão de seu banco de dados do aeroporto (usado pelo AeroNav e outros para compilar gráficos) para Postgres/PostGIS da Oracle.
O site avationDB também é construído sobre Postgres (8.0).

Se as consultas relacionadas ao GIS estiverem no centro do que você está fazendo, minha sugestão seria usar o Postgres. Ele certamente pode lidar com tudo o mais que você normalmente faria em um banco de dados relacional.

Em termos de mudança do MySQL, a documentação por trás do Postgres é de primeira linha, e também há uma seção do Oostgres Wiki sobre a mudança do MySQL para o Postgres .
A curva de aprendizado inicial pode ser um pouco íngreme e você pode precisar ajustar seu banco de dados e quaisquer procedimentos armazenados (se você já os tiver escrito para MySQL), mas não é uma tarefa intransponível.

Você deve ser capaz de pegar o suficiente para fazer a troca em algumas semanas e, se configurar um banco de dados de desenvolvimento, provavelmente poderá estar bem versado em tarefas de rotina em um mês e confiante de que sabe onde procurar no manual para os não tão rotineiros.

Falando de algumas coisas muito importantes. Aqui está uma lista de coisas que o PostGIS suporta que estão totalmente ausentes no MySQL e no MariaDB.

• SRID em cálculos, dê aos seus pontos um SRID diferente e você receberá valores diferentes de volta. Isto é prop Funções agregadas: até onde sei, o MySQL não oferece funções de agregação espacial

K vizinho mais próximo: Somente PostGIS suporta KNN. Encontre o ponto mais próximo de qualquer ponto usando apenas um índice: não há necessidade de calcular a distância de todos os pontos!er. O MySQL quebra a especificação e apenas verifica se dois valores têm o mesmo SRID. O PostGIS vem com um banco de dados de definições do pro4j para permitir o conhecimento SRID contínuo. Definir um SRID e chamar ST_Transform( uma função que falta ao MySQL ) irá reprojetar suas coordenadas.

No MySQL, todos os cálculos são feitos assumindo SRID 0, independentemente do valor SRID real. SRID 0 representa um plano cartesiano plano infinito sem unidades atribuídas aos seus eixos. No futuro, os cálculos podem usar os valores SRID especificados. Para garantir o comportamento de SRID 0, crie valores de geometria usando SRID 0. SRID 0 é o padrão para novos valores de geometria se nenhum SRID for especificado.

• Rasters : há uma tonelada de recursos aqui, desde a geração do raster até a extração. Você pode gerar mapas de calor e afins.

• Geografia , o PostGIS suporta um tipo de geografia não projetada que não usa matemática cartesiana. Tem toda uma lentidão de funções associadas que operam em esféricos oblatos. Por outro lado, o MySQL não pode nem mesmo criar uma caixa delimitadora em um SRS geográfico a partir de dois pontos.

• Topologia , diferente de geometrias vetoriais, geoms topo armazenam nós e relações. Mova um nó, a borda também se move e você obtém uma nova face. Isso também força as arestas a serem direcionadas, o que as torna ideais para roteamento. Como subponto, 100% do que o PgRouting faz não está disponível para o MySQL - então você simplesmente não pode criar um Google Maps ou algo parecido em cima dele.

• Geocodificação: há uma extensão de geocodificador no diretório contrib que trabalha com os dados do censo e um carregador para instalar esses dados.

• Padronização de endereço: existe uma extensão que lida com a normalização de endereços para fácil análise, armazenamento e comparação.

• Recursos do SQL-MM , você simplesmente não encontrará CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEou MULTISURFACEno MySQL.

• nd cabos: PostGIS pode suportar formas e pontos 3dm, 3dz e 4d e pontos que o MySQL simplesmente não pode

• O MySQL suporta apenas índices r-tree. PostGIS suporta r-tree (gist/gin) e BRIN (para grandes tabelas de geometria)

• Funções agregadas: até onde sei, o MySQL não oferece funções de agregação espacial

• K vizinho mais próximo: Somente PostGIS suporta KNN . Encontre o ponto mais próximo de qualquer ponto usando apenas um índice: não há necessidade de calcular a distância de todos os pontos!

• Indexação. O PostgreSQL permite que você armazene quaisquer dados em seu índice espacial (que é um índice gist/gin). Por exemplo, você pode armazenar o year(ou outros dados não espaciais) e geomno mesmo índice. Veja btree_gine btree_gistpara mais informações sobre como fazer isso.

Além disso, provavelmente existem mais de 200 funções suportadas pelo PostGIS.

Resumindo, o MySQL não se apega ao PostGIS e sabe disso. PostGIS é uma fera. Só queria explicar algumas dessas coisas.

Concordo totalmente com todas as afirmações da primeira resposta, mas compartilhando minha própria experiência - fiz isso na Administração Nacional de Estradas do meu país: crítico de produção, site de alto tráfego. Sugiro que um aplicativo da web seja alimentado por MySQL e PostgreSQL/PostGIS.

Para todas as coisas "típicas", o aplicativo da web funciona perfeitamente com um CMS baseado em MySQL. Para todas as tarefas espaciais, o mesmo aplicativo da web funciona - também perfeitamente;) com desenvolvimento personalizado baseado em PostgreSQL/PostGIS. O primeiro componente foi desenvolvido e é mantido sem esforço com habilidades normais do MySQL. O segundo componente envolveu um pouco mais de esforço de pesquisa no início.

Você não precisa forçar uma implementação dispendiosa de coisas típicas no não tão familiar PostgreSQL/PostGIS e também não precisa forçar uma implementação abaixo do ideal de coisas geoespaciais no MySQL. Deixe cada jogador jogar onde pode acertar.