Me gustaría almacenar algunas posiciones geométricas en mi base de datos MySQL. Para esto utilizo el tipo de datos POINT. Casi en todas partes leí que la función GeomFromTextdebería usarse para insertar datos en la tabla.

Sin embargo, descubrí que POINT(X,Y)también funciona. No encontré ninguna descripción de por qué GeomFromTextdebería usarse en lugar de POINT.

Por ejemplo, tengo la siguiente relación simple:

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

Y puedo insertar valores usando las siguientes dos variantes:

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

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

Cuando veo la tabla ( SELECT * FROM Site) veo el mismo blob binario para la ubicación, y cuando veo las coordenadas ( SELECT *, AsText(Position) FROM Site) también veo los mismos valores.

Entonces, ¿por qué se debe usar GeomFromText? ¿Existen diferencias de rendimiento (conocidas) entre estas dos variantes? ¿Cómo se resuelve esto en otros sistemas de bases de datos que MySQL?

Existen dos formatos binarios diferentes relacionados con las extensiones espaciales de MySQL, el formato "binario conocido" (WKB) de los estándares y el GEOMETRYtipo de datos interno de MySQL .

Antes de MySQL 5.1.35, funciones como POINT()no devolvían el tipo de datos interno de MySQL; devolvieron WKB ... así que antes de eso, tenías que hacer esto:

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

Pero ahora, como en su ejemplo, esto funciona:

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

Para el crédito de los desarrolladores, cuando cambiaron Point()y funciones similares para (más sensatamente) devolver GEOMETRYobjetos, permitieron que GeomFromWKB()funciones similares aceptaran datos de geometría WKB o MySQL como entrada, aunque las funciones están destinadas a aceptar WKB como entrada.

El hecho de que el primer método funcione (a pesar de ser técnicamente incorrecto) en servidores más nuevos y el segundo método no funcione antes de MySQL 5.1.35 podría explicar por qué los ejemplos se escribieron utilizando el enfoque que ha visto. evitar el problema por completo. De lo contrario ... no tengo nada, aquí.

Concatenar y luego analizar el texto parece intuitivamente más lento y más propenso a errores que las funciones que aceptan las variables adecuadas como entrada, por lo que no puedo pensar en ningún motivo para crear cadenas concatenadas y usar las funciones basadas en 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 la posteridad lo único que importa es

• Point(X,Y)es un constructor de números con precisión y no requiere conversión primero a texto, lo que lo hace más rápido. También se garantiza DEVOLVER A POINTO FALLAR . Esto lo hace fuertemente tipado si quieres pensarlo así.
• Constructores de texto conocido (WKT) : estos son siempre más lentos, ya que requieren un paso adicional para analizar el texto conocido (WKT) . Tenga en cuenta que en versiones anteriores se pueden encontrar sin el ST_prefijo; donde esté disponible, use la versión con el ST_prefijo. Utilice los constructores WKT solo si su entrada ya es texto conocido. Si no, use el Point(x,y)constructor anterior.
  • ST_GeomFromText(wkt, srid)puede devolver CUALQUIER tipo espacial que sea compatible con MySQL y pueda ser representado por WKT. Esto hace que esté tipeado libremente si quieres pensarlo así.
  • ST_PointFromText(wkt, srid)un POINTconstructor fuertemente tipado de texto conocido.

Claridad

Saltarse la lección de historia, NUNCA lo haga GeomFromText(Point(x,y)). Eso es horrible, sin apoyo e indocumentado.

Con GeomFromText o cualquier otra función * FromText puede especificar el SRID . No creo que puedas hacerlo de otra manera.

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