Il prefisso ST_ è appropriato per le funzioni non incluse in SQL / MM Parte 3?


12

Stavo leggendo un thread sull'estensione geospaziale di Presto in questo numero di Github , in cui è line_locate_pointstata introdotta una funzione . Era basato sulla ST_LineLocatePointfunzione di PostGIS , che restituisce un galleggiante che rappresenta la frazione lungo una linea del punto più vicino su quella linea in una determinata posizione.

La domanda è stata sollevata perché è stato nominato line_locate_pointe non ST_LineLocatePointcome la versione PostGIS. La risposta è stata che questa funzione non esiste nello standard SQL / MM Parte 3 e quindi non dovrebbe iniziare con ST_.

Leggendo rapidamente lo standard, non vedo alcun commento su come gestire i casi in cui si introduce una funzione spaziale nel database che non è nello standard. Lo spirito del ST_prefisso è quello di differenziare le funzioni spaziali da quelle non spaziali (come sembra essere il caso di PostGIS), o è per indicare che la funzione è conforme a una funzione equivalente in SQL / MM Parte 3?

Osservando lo stato attuale dell'API di Presto , devo dire che quest'ultimo approccio sembra meno pulito e introduce un po 'di confusione sul perché i nomi non sono coerenti, ma forse questo potrebbe essere affrontato da una semplice nota in alto.

La mia domanda, quindi, è se c'è qualche aspetto dello standard che sto trascurando che consente di estenderlo oltre l'insieme definito di oggetti spaziali o, in alternativa, se ciò è espressamente vietato da una regola scritta o non scritta dei seguenti standard .


Penso che sia una domanda giusta, ma essenzialmente si riduce a una questione di opinione. Mi aspetto che tutte le funzioni che siano manifestamente spaziali, cioè che operino su un vettore, raster, topologia, superficie 3D, ecc., Prendano il prefisso ST_. Non mi era mai venuto in mente di chiedere se questo fosse un uso appropriato in base al fatto che fosse o meno in una specifica. Sebbene l'interoperabilità sia importante e desiderabile, certamente non vorrei che Postgis fosse trattenuto implementando solo le funzioni nelle specifiche SQL / MM. E penso che usare qualche altro prefisso causerebbe molta confusione.
John Powell,

Non capisco perché la mia domanda sia stata semplicemente sospesa per essere "basata sull'opinione". La mia domanda è esplicitamente sul fatto che è opinione a base di, o se c'è qualche aspetto dello standard che sto con vista che rende questa decisione infatti basata-.
Brideau,

Mi scuso, ho appena riletto la tua domanda e in effetti c'è una domanda chiara, non basata sull'opinione. Il mio 2c è che se è esplicitamente spaziale, ottiene un ST_, indipendentemente dal fatto che sia o meno negli standard. Ho espresso un voto di riapertura.
John Powell,

Per me è basato sull'opinione. Lo standard SQL / MM non può negare agli sviluppatori di creare le proprie funzioni con prefisso ST_ se lo desiderano, anche le funzioni non spaziali. Tuttavia, gli sviluppatori potrebbero meritare di farlo in un altro modo. Per fare un confronto, SpatiaLite ha molte funzioni spaziali ma non SQL / MM che hanno sinonimi ST_, alcune altre che non hanno gaia-gis.it/gaia-sins/spatialite-sql-latest.html .
user30184

Se SQL / MM possa o meno forzare uno sviluppatore a fare qualcosa non è la domanda che sto ponendo. Sto chiedendo cosa raccomanda lo standard stesso. Lo standard è lungo 1500 pagine e non ne ho letto ogni riga, quindi sto chiedendo alla community qui - alcuni dei quali aiutano a scriverlo e gli standard correlati - cosa è raccomandato, o forse se difende queste decisioni un altro standard o scelto esplicitamente di non affrontare questo. Queste sono richieste basate sui fatti.
Brideau,

Risposte:


1

Le specifiche OpenSpatial dicono numerose cose al riguardo,

Quando si integra questo SQL con quello di SQL / MM, il prefisso del tipo " ST_" deve essere usato come appropriato.

E,

I nomi delle classi in SQL / MM portano un " ST_" prefisso. Questo è facoltativo e le implementazioni possono scegliere di eliminare questo prefisso come è stato fatto in vari punti di questo standard.

Da questo Comitato Progetto di ISO / IEC CD13249-3 ed 5

Questa parte di ISO / IEC 13249 utilizza il prefisso ST_per tipo definito dall'utente, attributo, instradabile richiamato da SQL e nomi di vista. Questa parte di ISO / IEC 13249 utilizza il prefisso ' ST_Private' per i nomi di determinati attributi. L'uso di " ST_Private" indica che l'attributo non è per uso pubblico.

Quindi ecco quello che abbiamo,

  • SQL / MM suggerisce di utilizzare il prefisso.
  • SQL / MM afferma che il prefisso è tuttavia facoltativo.
  • ISO usa anche il ST_prefisso ..

Direi questo

  • L'uso di ST_dovrebbe essere considerato come parole chiave non riservate per gli utenti finali. Non c'è davvero alcun motivo per rendere le funzioni dell'utente finale con questo prefisso. Stai meglio usando solo STx_. Conosciamo almeno due corpi che hanno pubblicato con questo prefisso suggerimenti (OpenSpatial) SQL / MM e ISO. Inoltre, molti simboli RDBMS inquinano con quel prefisso.

Potrebbe esserci di più nella storia, ma non riesco a trovare altre informazioni contemporanee su questo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.