Eu gostaria de armazenar algumas posições geométricas no meu banco de dados MySQL. Para isso, eu uso o tipo de dados POINT. Em quase todos os lugares, li que a função GeomFromTextdeve ser usada para inserir dados na tabela.

No entanto, descobri que POINT(X,Y)também funciona. Não encontrei nenhuma descrição do porquê GeomFromTextusar em vez de POINT.

Por exemplo, tenho a seguinte relação simples:

CREATE TABLE Site (
    SiteID      BIGINT UNSIGNED,
    Position    POINT
);

E posso inserir valores usando as duas seguintes variantes:

INSERT INTO Site (
    1,
    GeomFromText( 'POINT(48.19976 16.45572)' )
);

INSERT INTO Site (
    2,
    POINT(48.19976, 16.45572)
);

Quando visualizo a tabela ( SELECT * FROM Site), vejo o mesmo blob binário do local e, quando visualizo as coordenadas ( SELECT *, AsText(Position) FROM Site), também vejo os mesmos valores.

Então, por que o GeomFromText deve ser usado? Existem diferenças de desempenho (conhecidas) entre essas duas variantes? Como isso é resolvido em outros sistemas de banco de dados que não o MySQL?

Existem dois formatos binários diferentes relacionados às extensões espaciais do MySQL, o formato "bem conhecido binário" (WKB) dos padrões e o GEOMETRYtipo de dados interno do MySQL .

Antes do MySQL 5.1.35, funções como POINT()não retornavam o tipo de dados interno do MySQL; eles retornaram o WKB ... então antes disso, você tinha que fazer o seguinte:

INSERT INTO t1 (pt_col) VALUES (GeomFromWKB(Point(1,2)));

Mas agora, como no seu exemplo, isso funciona:

INSERT INTO t1 (pt_col) VALUES(Point(1,2));

Para crédito dos desenvolvedores, quando eles mudaram Point()e funções semelhantes para retornar GEOMETRYobjetos (com mais prudência) , eles permitiram que GeomFromWKB()funções semelhantes aceitassem realmente dados WKB ou MySQL Geometry como entrada, mesmo que as funções pretendam aceitar WKB como entrada.

O fato de o 1º método funcionar (apesar de tecnicamente errado) em servidores mais recentes e o 2º método não funcionar antes do MySQL 5.1.35 pode explicar por que os exemplos foram escritos usando a abordagem que você já viu - para evite o problema completamente. Caso contrário ... não tenho nada aqui.

Concatenar e depois analisar o texto parece intuitivamente mais lento e propenso a erros do que as funções que aceitam variáveis ​​apropriadas como entrada; portanto, não consigo pensar em nenhum motivo para criar seqüências de caracteres concatenadas e usar as funções baseadas em texto.

http://dev.mysql.com/doc/refman/5.1/en/creating-spatial-values.html#gis-wkb-functions

http://dev.mysql.com/doc/relnotes/mysql/5.1/en/news-5-1-35.html

MySQL 8+

Para a posteridade, a única coisa que importa é que

• Point(X,Y)é um construtor de números com precisão e não requer conversão primeiro em texto, tornando-o mais rápido. Também é garantido RETORNAR POINTOU FALHAR . Isso o torna fortemente digitado, se você quiser pensar assim.
• Construtores de texto conhecido (WKT) : esses são sempre mais lentos, pois exigem uma etapa adicional para analisar o texto conhecido (WKT) . Observe que em versões mais antigas, elas poderiam ser encontradas sem o ST_prefixo; Onde disponível, use a versão com o ST_prefixo. Use os construtores WKT apenas se sua entrada já for um texto conhecido. Caso contrário, use o Point(x,y)construtor acima.
  • ST_GeomFromText(wkt, srid)pode retornar QUALQUER tipo espacial suportado pelo MySQL e representado pelo WKT. Isso o torna vagamente digitado se você quiser pensar assim.
  • ST_PointFromText(wkt, srid)um POINTconstrutor fortemente tipado do texto conhecido.

Clareza

Ignorando a lição de história, NUNCA faça GeomFromText(Point(x,y)). Isso é horrível, sem suporte e sem documentos.

Com o GeomFromText ou qualquer outra função * FromText, você pode especificar o SRID . Eu não acho que você possa fazê-lo de outra forma.

PointFromText('POINT(lat lng)', 4326)