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 GeomFromText
devait être utilisée pour insérer des données dans la table.
Cependant, j'ai découvert que POINT(X,Y)
fonctionne également. Je n'ai trouvé aucune description pourquoi GeomFromText
devrait être utilisé à 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 consulte le tableau (SELECT * FROM Site
), Je vois le même blob binaire pour l'emplacement, et lorsque je consulte les coordonnées (SELECT *, AsText(Position) FROM Site
), je vois également 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 type de données interne MySQL GEOMETRY
.
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 modifié Point()
et des fonctions similaires pour (plus sainement) renvoyer des objets GEOMETRY
, ils ont permis à GeomFromWKB()
et à des fonctions similaires d'accepter réellement WKB ou données de géométrie MySQL 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
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 RETOUR A POINT
OR FAIL . Cela fait donc fortement tapé si vous voulez y penser comme ça.ST_
; si disponible, utilisez la version avec le préfixe ST_
. Utilisez les constructeurs WKT uniquement si votre entrée est déjà du texte connu. Sinon, utilisez le constructeur Point(x,y)
ci-dessus. ST_GeomFromText(wkt, srid)
peut renvoyer [~ # ~] tout type spatial [~ # ~] pris en charge par MySQL et peut être représenté par WKT. Cela le rend vaguement tapé si vous voulez y penser comme ça.ST_PointFromText(wkt, srid)
un constructeur POINT
- fortement typé à partir d'un texte bien connu.Ignorer la leçon d'histoire, [~ # ~] jamais [~ # ~] faire GeomFromText(Point(x,y))
. C'est horrible, sans support et sans papiers.