MySQL veritabanımda bazı geometrik pozisyonları saklamak istiyorum. Bunun için POINT veri tipini kullanıyorum. Hemen hemen her yerde fonksiyonun GeomFromTexttabloya veri eklemek için kullanılması gerektiğini okudum .

Ancak, bunun POINT(X,Y)da işe yaradığını öğrendim . Bunun GeomFromTextyerine neden kullanılması gerektiğine dair bir açıklama bulamadım POINT.

Örneğin ben aşağıdaki basit bir ilişki var:

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

Ve aşağıdaki iki varyantı kullanarak değerler ekleyebilirim:

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

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

Tabloya ( SELECT * FROM Site) baktığımda konum için aynı ikili blob görüyorum ve koordinatları ( SELECT *, AsText(Position) FROM Site) gördüğümde de aynı değerleri görüyorum.

Peki GeomFromText neden kullanılmalı? Bu iki değişken arasında (bilinen) performans farklılıkları var mı? Bu MySQL dışındaki diğer veritabanı sistemlerinde nasıl çözülür?

MySQL uzamsal uzantılarıyla ilgili iki farklı ikili format vardır , standartlardan "iyi bilinen ikili" (WKB) formatı ve MySQL dahili GEOMETRYveri türü.

MySQL 5.1.35'ten önce, gibi işlevler POINT()MySQL dahili veri türünü döndürmedi; WKB'ye geri döndüler ... o zamandan önce bunu yapmak zorundaydınız:

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

Ama şimdi, örneğinizde olduğu gibi, bu işe yarıyor:

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

Geliştiricilerin kredisine göre, değiştiklerinde Point()ve benzer işlevleri (daha güvenli bir şekilde) dönüş GEOMETRYnesnelerine dönüştürdüklerinde, GeomFromWKB()işlevlerin WKB'yi giriş olarak kabul etmesine rağmen, WKB veya MySQL Geometri verilerini giriş olarak kabul etmelerine izin verdiler .

MySQL 5.1.35'ten önce 1. yöntemin daha yeni sunucularda (teknik olarak yanlış olmasına rağmen) ve 2. yöntemin hiç çalışmıyor olması, gördüğünüz yaklaşım kullanılarak örneklerin neden yazıldığını açıklayabilir - sorunu tamamen önleyin. Aksi halde ... Burada hiçbir şeyim yok.

Metin birleştirmek ve sonra ayrıştırmak sezgisel olarak daha yavaş ve girdi olarak uygun değişkenleri kabul fonksiyonları daha hata eğilimli görünüyor, bu yüzden birleştirilmiş dizeleri zanaat ve metin tabanlı işlevleri kullanmak için herhangi bir neden düşünemiyorum.

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+

Gelecek kuşaklar için önemli olan tek şey

• Point(X,Y)hassas sayılar için bir yapıcıdır ve önce metne dönüştürmeyi gerektirmez. Ayrıca A POINTVEYA BAŞARISIZ DÖNÜŞ garanti edilir . Bu şekilde düşünmek istiyorsanız , onu güçlü bir şekilde yazıyor.
• Metin (WKT) Tanınmış kurucular: bunlar hep onlar ayrıştırmak için ilave bir adım gerektirir olarak, yavaş Tanınmış metin (WKT) . Eski sürümlerde bunların ST_önek olmadan bulunabileceğini unutmayın ; varsa, ST_öneki olan sürümü kullanın . WKT yapıcılarını yalnızca girişiniz zaten iyi bilinen bir metinse kullanın. Değilse, Point(x,y)yukarıdaki yapıcıyı kullanın .
  • ST_GeomFromText(wkt, srid)MySQL tarafından desteklenen ve WKT tarafından temsil edilebilen HERHANGİ bir uzamsal tür döndürebilir . Bu şekilde düşünmek istiyorsanız , onu gevşek yazıyor.
  • ST_PointFromText(wkt, srid)POINTİyi bilinen bir metinden güçlü bir şekilde yazılmış bir yapıcı.

berraklık

Tarih dersini atlamayın, ASLA yapmayın GeomFromText(Point(x,y)). Bu korkunç, desteklenmeyen ve belgesiz.

GeomFromText veya başka herhangi * FromText ile belirtebilirsiniz işlev SRID . Başka türlü yapabileceğini sanmıyorum.

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