Чи підходить префікс ST_ для функцій, не включених до частини SQL / MM 3?


12

Я читав нитку про геопросторове розширення для Presto в цьому випуску Github , де line_locate_pointбула представлена функція . Він базувався на ST_LineLocatePointфункції PostGIS , яка повертає поплавок, що представляє дріб через лінію найближчої точки на цій лінії до заданого місця.

Було поставлено питання, чому вона названа line_locate_pointта не ST_LineLocatePointсхожа на версію PostGIS. Відповідь полягала в тому, що ця функція не існує в стандарті SQL / MM Частина 3, і тому вона не повинна починатися з ST_.

Читаючи швидко стандарт, я не бачу жодних коментарів щодо того, як обробляти випадки, коли ви вводите просторову функцію до вашої бази даних, яка не є стандартом. Чи є дух ST_префікса для того, щоб відрізняти просторові функції від непросторових функцій (як це здається у PostGIS), чи це означає, що функція відповідає еквівалентній функції в SQL / MM Частина 3?

Дивлячись на поточний стан API Presto , я мушу сказати, що останній підхід виглядає менш чистою і вносить певну плутанину щодо того, чому імена не відповідають, але, можливо, це можна вирішити простою приміткою вгорі.

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


Я думаю, це справедливе питання, але, по суті, зводиться до питання думки. Я очікую, що всі функції, явно просторові, тобто вони працюють на векторі, растрі, топології, 3D поверхні тощо, приймуть префікс ST_. Мені ніколи не виникало питання запитати, чи це правильне використання виходячи з того, було воно в специфікації чи ні. Хоча сумісність важлива і бажана, я, звичайно, не хотів би, щоб Postgis стримувався лише реалізацією функцій у специфікації SQL / MM. І я думаю, що використання якогось іншого префікса призведе до великої плутанини.
Джон Пауелл

Я не розумію, чому моє запитання було просто відкладено за те, що він "базується на думці". Моє питання явно про те , що це думка на основі, або якщо є якийсь - то аспект стандарту я з видом , що робить це рішення на основі фактів.
Бридо

Вибачте, я щойно перечитав ваше запитання, і там дійсно є чітке питання, не засноване на думці. Мій 2c полягає в тому, що якщо він явно просторовий, він отримує ST_, незалежно від того, є він у стандартах чи ні. Я голосувати повторно.
Джон Пауелл

На мій погляд, це засноване на думці. Стандарт SQL / MM не може заборонити розробникам створювати власні функції з префіксом ST_, якщо вони хочуть, навіть непросторові функції. Однак розробники можуть вирішити це зробити іншим способом. Для порівняння, SpatiaLite має багато просторових, але не-SQL / MM функцій, які мають ST_ синоніми, деякі інші, які не мають gaia-gis.it/gaia-sins/spatialite-sql-latest.html .
користувач30184

Чи може я SQL / MM змусити розробника щось робити, чи ні, це не запитання. Я запитую про те, що рекомендує сам стандарт. Стандарт становить 1500 сторінок, і я не читав його кожного рядка, тому я прошу спільноту - дехто з них допомагає написати та відповідні стандарти - що рекомендується, чи, можливо, він відкладає ці рішення на інший стандарт або явно вирішив не вирішувати це питання. Це запити на основі фактів.
Бридо

Відповіді:


1

Специфікація OpenSpatial говорить про це багато речей,

При інтеграції цього SQL з таким SQL / MM ST_слід використовувати префікс назви типу " ", якщо це доречно.

І,

Назви класів у SQL / MM мають " ST_" префікс. Це необов’язково, і в реалізаціях може бути вибрано скинути цей префікс, як це було зроблено в різних місцях цього стандарту.

Із цього Комітету проект ISO / IEC CD13249-3 ed 5

Ця частина ISO / IEC 13249 використовує префікс ST_для визначеного користувачем типу, атрибута, виклику SQL, що викликається програмою, та перегляду імен. У цій частині ISO / IEC 13249 використовується префікс ' ST_Private' для імен певних атрибутів. Використання ' ST_Private' означає, що атрибут не для загального користування.

Отже, ось що ми маємо,

  • SQL / MM пропонує використовувати префікс.
  • SQL / MM каже, що префікс є необов'язковим.
  • ISO також використовує ST_префікс ..

Я б сказав це,

  • Використання ST_слід розглядати як незарезервовані ключові слова для кінцевих користувачів. Дійсно немає причин робити функції кінцевого користувача з цим префіксом. Вам краще просто використовувати STx_. Нам відомо щонайменше два органи, які опублікували пропозиції щодо цього префікса (OpenSpatial) SQL / MM та ISO. Крім того, багато символів забруднення RDBMS з цим префіксом.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.