Vorrei memorizzare alcune posizioni geometriche nel mio database MySQL. Per questo utilizzo il tipo di dati POINT. Quasi ovunque leggo che la funzione GeomFromTextdovrebbe essere utilizzata per inserire dati nella tabella.

Tuttavia, ho scoperto che POINT(X,Y)funziona anche. Non ho trovato alcuna descrizione del motivo per cui GeomFromTextdovrebbe essere utilizzato invece di POINT.

Ad esempio ho la seguente semplice relazione:

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

E posso inserire valori usando le seguenti due varianti:

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

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

Quando visualizzo la tabella ( SELECT * FROM Site) vedo lo stesso BLOB binario per la posizione e quando visualizzo le coordinate ( SELECT *, AsText(Position) FROM Site) vedo anche gli stessi valori.

Quindi perché usare GeomFromText? Ci sono differenze di prestazioni (conosciute) tra queste due varianti? Come viene risolto in altri sistemi di database diversi da MySQL?

Esistono due diversi formati binari relativi alle estensioni spaziali MySQL, il formato "ben noto binario" (WKB) dagli standard e il GEOMETRYtipo di dati interno MySQL .

Prima di MySQL 5.1.35, funzioni come POINT()non restituivano il tipo di dati interno MySQL; hanno restituito WKB ... quindi prima di allora, dovevi farlo:

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

Ma ora, come nel tuo esempio, questo funziona:

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

A credito degli sviluppatori, quando hanno cambiato Point()e funzioni simili a (più saggiamente) restituiscono GEOMETRYoggetti, hanno permesso GeomFromWKB()e funzioni simili di accettare effettivamente dati WKB o MySQL Geometry come input anche se le funzioni intendono accettare WKB come input.

Il fatto che il 1o metodo funzioni (nonostante sia tecnicamente sbagliato) su server più recenti e il 2o metodo non funziona affatto prima di MySQL 5.1.35 potrebbe spiegare perché gli esempi sono stati scritti usando l'approccio che hai visto evitare del tutto il problema. Altrimenti ... Non ho niente, qui.

Concatenare e quindi analizzare il testo sembra intuitivamente più lento e più soggetto a errori rispetto alle funzioni che accettano le variabili appropriate come input, quindi non riesco a pensare a nessun motivo per creare stringhe concatenate e utilizzare le funzioni basate sul testo.

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+

Per i posteri l'unica cosa che conta

• Point(X,Y)è un costruttore di numeri con precisione e non richiede la prima conversione in testo rendendolo più veloce. È inoltre garantito il RESO A POINTO FAIL . Questo lo rende fortemente tipizzato se vuoi pensarlo in quel modo.
• Costruttori di testi ben noti (WKT) : sono sempre più lenti, poiché richiedono un passaggio aggiuntivo per analizzare il testo ben noto (WKT) . Nota nelle versioni precedenti queste potrebbero essere trovate senza il ST_prefisso; ove disponibile, utilizzare la versione con il ST_prefisso. Usa i costruttori WKT solo se il tuo input è già noto. In caso contrario, utilizzare il Point(x,y)costruttore sopra.
  • ST_GeomFromText(wkt, srid)può restituire QUALSIASI tipo spaziale supportato da MySQL e rappresentato da WKT. Questo lo rende vagamente digitato se vuoi pensarlo in quel modo.
  • ST_PointFromText(wkt, srid)un POINTcostruttore fortemente tipizzato di testo ben noto.

Chiarezza

Saltare la lezione di storia, MAI farlo GeomFromText(Point(x,y)). È orribile, non supportato e non documentato.

Con GeomFromText o qualsiasi altra funzione * FromText è possibile specificare SRID . Non penso che tu possa farlo diversamente.

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