Ich möchte einige geometrische Positionen in meiner MySQL-Datenbank speichern. Dafür verwende ich den Datentyp POINT. Fast überall las ich, dass die Funktion GeomFromTextverwendet werden sollte, um Daten in die Tabelle einzufügen.

Ich fand jedoch heraus, dass das POINT(X,Y)auch funktioniert. Ich habe keine Beschreibung gefunden, warum statt GeomFromTextverwendet werden sollte POINT.

Zum Beispiel habe ich die folgende einfache Beziehung:

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

Und ich kann Werte mit den folgenden zwei Varianten einfügen:

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

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

Wenn ich die Tabelle ansehe ( SELECT * FROM Site), sehe ich den gleichen binären Blob für die Position, und wenn ich die Koordinaten ansehe ( SELECT *, AsText(Position) FROM Site), sehe ich auch die gleichen Werte.

Warum sollte GeomFromText verwendet werden? Gibt es (bekannte) Leistungsunterschiede zwischen diesen beiden Varianten? Wie wird dies in anderen Datenbanksystemen als MySQL gelöst?

Es gibt zwei verschiedene Binärformate für die räumlichen Erweiterungen von MySQL, das aus den Standards bekannte Binärformat (WKB) und den internen MySQL- GEOMETRYDatentyp.

Vor MySQL 5.1.35 funktioniert das wie POINT() den internen MySQL-Datentyp nicht zurückgegeben. Sie haben WKB zurückgegeben. Vorher mussten Sie Folgendes tun:

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

Aber jetzt, wie in Ihrem Beispiel, funktioniert Folgendes:

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

Zum Wohle der Entwickler, wenn sie sich geändert haben Point() und ähnliche Funktionen verwenden, um GEOMETRYObjekte (sicherer) zurückzugeben , können sie GeomFromWKB()WKB- oder MySQL-Geometriedaten als Eingabe akzeptieren, obwohl die Funktionen WKB als Eingabe akzeptieren sollen.

Die Tatsache, dass die 1. Methode (obwohl technisch falsch) auf neueren Servern funktioniert und die 2. Methode vor MySQL 5.1.35 überhaupt nicht funktioniert könnte erklären, warum Beispiele mit dem von Ihnen Ansatz geschrieben wurden Vermeiden Sie das Problem vollständig. Ansonsten ... ich habe hier nichts.

Das Verketten und anschließende Parsen von Text scheint intuitiv langsamer und fehleranfälliger zu sein als Funktionen, die korrekte Variablen als Eingabe akzeptieren. Daher kann ich mir keinen Grund vorstellen, verkettete Zeichenfolgen zu erstellen und die textbasierten Funktionen zu verwenden.

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+

Für die Nachwelt das Einzige, worauf es ankommt

• Point(X,Y)ist ein Konstruktor für Zahlen mit Präzision und erfordert keine Konvertierung in Text, um diese schneller zu machen. Es ist auch garantiert, A oder POINTFAIL RÜCKZUFÜHREN . Dies macht es stark getippt, wenn Sie so darüber nachdenken möchten.
• Well-Known Text (WKT) Bauer: Das ist immer langsamer, da sie einen Additionsschritt erfordern die analysieren Well-Known Text (WKT) . Beachten Sie, dass in älteren Versionen diese ohne das ST_Präfix gefunden werden können . Verwenden Sie, sofern verfügbar, die Version mit dem ST_Präfix. Verwenden Sie die WKT-Konstruktoren nur, wenn Ihre Eingabe bereits bekannter Text ist. Wenn nicht, benutze den Point(x,y)obigen Konstruktor.
  • ST_GeomFromText(wkt, srid)kann JEDEN räumlichen Typ zurückgeben, der von MySQL unterstützt und von WKT dargestellt wird. Dies macht es lose getippt, wenn Sie so darüber nachdenken möchten.
  • ST_PointFromText(wkt, srid)ein stark typisierter POINTKonstruktor aus bekanntem Text.

Klarheit

Überspringen der Geschichtsstunde, nie tun GeomFromText(Point(x,y)). Das ist schrecklich, nicht unterstützt und ohne Papiere.

Mit GeomFromText oder einer anderen * FromText-Funktion können Sie die SRID angeben . Ich glaube nicht, dass Sie es anders machen können.

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