Je voudrais stocker quelques positions géométriques dans ma base de données MySQL. Pour cela, j'utilise le type de données POINT. Presque partout, j'ai lu que la fonction GeomFromTextdevait être utilisée pour insérer des données dans le tableau.

Cependant, j'ai découvert que cela POINT(X,Y)fonctionne également. Je n'ai trouvé aucune description pourquoi GeomFromTextutiliser à la place de POINT.

Par exemple, j'ai la relation simple suivante:

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

Et je peux insérer des valeurs en utilisant les deux variantes suivantes:

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

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

Lorsque je vois la table ( SELECT * FROM Site), je vois le même blob binaire pour l'emplacement, et quand je vois les coordonnées ( SELECT *, AsText(Position) FROM Site), je vois aussi les mêmes valeurs.

Alors pourquoi utiliser GeomFromText? Existe-t-il des différences de performances (connues) entre ces deux variantes? Comment cela est-il résolu dans d'autres systèmes de base de données que MySQL?

Il existe deux formats binaires différents liés aux extensions spatiales MySQL, le format "bien connu binaire" (WKB) des normes et le GEOMETRYtype de données interne MySQL .

Avant MySQL 5.1.35, les fonctions comme POINT()ne renvoyaient pas le type de données interne MySQL; ils sont retournés WKB ... donc avant cela, vous deviez faire ceci:

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

Mais maintenant, comme dans votre exemple, cela fonctionne:

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

Au crédit des développeurs, lorsqu'ils ont changé Point()et des fonctions similaires pour retourner (plus sainement) des GEOMETRYobjets, ils ont autorisé GeomFromWKB()et des fonctions similaires à accepter réellement les données WKB ou MySQL Geometry en entrée, même si les fonctions sont destinées à accepter WKB en entrée.

Le fait que la 1ère méthode fonctionne (bien qu'elle soit techniquement erronée) sur les serveurs plus récents et que la 2ème méthode ne fonctionne pas du tout avant MySQL 5.1.35 pourrait expliquer pourquoi des exemples ont été écrits en utilisant l'approche que vous avez vue - pour éviter complètement le problème. Sinon ... je n'ai rien, ici.

La concaténation puis l'analyse du texte semblent intuitivement plus lentes et plus sujettes aux erreurs que les fonctions qui acceptent les variables appropriées en entrée, donc je ne vois aucune raison de créer des chaînes concaténées et d'utiliser les fonctions basées sur le texte.

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+

Pour la postérité, la seule chose qui compte c'est que

• Point(X,Y)est un constructeur pour les nombres avec précision et ne nécessite pas de convertir d'abord en texte pour le rendre plus rapide. Il est également garanti de RETOURNER POINTOU D'ÉCHEC . Cela le rend fortement typé si vous voulez y penser comme ça.
• Constructeurs de texte bien connu (WKT) : ils sont toujours plus lents, car ils nécessitent une étape supplémentaire pour analyser le texte bien connu (WKT) . Notez que dans les anciennes versions, celles-ci pouvaient être trouvées sans le ST_préfixe; le cas échéant, utilisez la version avec le ST_préfixe. Utilisez les constructeurs WKT uniquement si votre entrée est déjà du texte connu. Sinon, utilisez le Point(x,y)constructeur ci-dessus.
  • ST_GeomFromText(wkt, srid)peut renvoyer N'IMPORTE QUEL type spatial pris en charge par MySQL et représenté par WKT. Cela le rend vaguement tapé si vous voulez y penser comme ça.
  • ST_PointFromText(wkt, srid)un POINTconstructeur fortement typé à partir d'un texte bien connu.

Clarté

Sauter la leçon d'histoire, ne le faites JAMAISGeomFromText(Point(x,y)) . C'est horrible, sans support et sans papiers.

Avec GeomFromText ou toute autre fonction * FromText, vous pouvez spécifier le SRID . Je ne pense pas que vous puissiez le faire autrement.

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