Я хотів би зберегти деякі геометричні положення у моїй базі даних MySQL. Для цього я використовую тип даних POINT. Майже скрізь я читав, що функціяGeomFromText слід використовувати для вставки даних у таблицю.

Однак я з’ясував, що POINT(X,Y)також працює. Я не знайшов жодного опису, чому його GeomFromTextслід використовувати замість POINT.

Наприклад, у мене таке просте відношення:

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

І я можу вставити значення, використовуючи наступні два варіанти:

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

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

Коли я переглядаю таблицю ( SELECT * FROM Site), я бачу ту саму бінарну крапку для розташування, а коли я переглядаю координати ( SELECT *, AsText(Position) FROM Site), я також бачу однакові значення.

То навіщо використовувати GeomFromText? Чи існують (відомі) відмінності в роботі між цими двома варіантами? Як це вирішується в інших системах баз даних, крім MySQL?

Існує два різні бінарні формати, пов'язані з просторовими розширеннями MySQL, "добре відомим бінарним" (WKB) форматом зі стандартів та внутрішнім GEOMETRYтипом даних MySQL .

До MySQL 5.1.35 такі функції, як, наприклад POINT(), не повернули внутрішній тип даних MySQL; вони повернули WKB ... так що раніше, ви повинні були зробити це:

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

Але тепер, як у вашому прикладі, це працює:

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

На Point()відміну від розробників, коли вони змінили і подібні функції (більш розумно) повертали GEOMETRYоб'єкти, вони дозволили GeomFromWKB()подібним функціям фактично приймати дані WKB або MySQL Geometry як вхідні дані, навіть якщо функції призначені приймати WKB як вхідні дані.

Той факт, що 1-й метод працює (незважаючи на технічну помилку) на новіших серверах, а другий метод взагалі не працює до MySQL 5.1.35, може пояснити, чому приклади були написані з використанням підходу, який ви бачили - уникайте проблеми цілком. Інакше ... тут я нічого не маю.

З'єднання та розбір тексту здається інтуїтивно повільнішим і більш схильним до помилок, ніж функції, які приймають власні змінні в якості вхідних даних, тому я не можу придумати жодної причини для створення об'єднаних рядків та використання текстових функцій.

http://dev.mysql.com/doc/refman/5.1/uk/creating-spatial-values.html#gis-wkb-functions

http://dev.mysql.com/doc/relnotes/mysql/5.1/uk/news-5-1-35.html

MySQL 8+

Для нащадків важливо лише це

• Point(X,Y)є конструктором для чисел з точністю і не потребує перетворення спочатку в текст, що робить його швидшим. Це також гарантує повертають POINTабо зазнати невдачі . Це робить його сильно набраним, якщо ви хочете думати про це так.
• Добре відомі конструктори тексту (WKT) : вони завжди повільніші, оскільки вони потребують додаткового кроку для розбору добре відомого тексту (WKT) . Зауважте, що у старих версіях їх можна знайти без ST_префікса; якщо є, використовуйте версію з ST_префіксом. Використовуйте WKT-конструктори лише у тому випадку, якщо ваш текст уже відомий текст. Якщо ні, використовуйте Point(x,y)конструктор вище.
  • ST_GeomFromText(wkt, srid)може повернути будь-який просторовий тип, який підтримується MySQL і може бути представлений WKT. Це робить його вільно надрукував , якщо ви хочете , щоб думати про нього , як це.
  • ST_PointFromText(wkt, srid)сильно набраний POINT-конструктор з добре відомого тексту.

Чіткість

Пропускаючи урок історії, НІКОЛИ не робіть GeomFromText(Point(x,y)). Це жахливо, непідтримувано та бездокументовано.

За допомогою GeomFromText або будь-якої іншої функції * FromText ви можете вказати SRID . Я не думаю, що ти можеш це зробити інакше.

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