O prefixo ST_ é apropriado para funções não incluídas no SQL / MM Parte 3?


12

Eu estava lendo um tópico sobre a extensão geoespacial do Presto nesta edição do Github , onde uma função line_locate_pointfoi introduzida. Foi baseado na ST_LineLocatePointfunção do PostGIS , que retorna um ponto flutuante representando a fração ao longo de uma linha do ponto mais próximo dessa linha para um determinado local.

A questão foi levantada por que foi nomeado line_locate_pointe não ST_LineLocatePointcomo a versão PostGIS. A resposta foi que essa função não existe no padrão SQL / MM Parte 3 e, portanto, não deve ser iniciada ST_.

Lendo rapidamente o padrão, não vejo comentários sobre como lidar com casos em que você introduz uma função espacial no banco de dados que não está no padrão. O espírito do ST_prefixo é diferenciar funções espaciais de funções não espaciais (como parece ser o caso do PostGIS) ou indica que a função está em conformidade com uma função equivalente na Parte 3 do SQL / MM?

Observando o estado atual da API do Presto , devo dizer que a última abordagem parece menos limpa e introduz alguma confusão sobre o motivo dos nomes não serem consistentes, mas talvez isso possa ser resolvido com uma simples observação no topo.

Minha pergunta, então, é se existe algum aspecto do padrão que estou ignorando que permite extensões além do conjunto definido de objetos espaciais ou, alternativamente, se isso é expressamente proibido por alguma regra escrita ou não escrita dos seguintes padrões .


Eu acho que é uma pergunta justa, mas essencialmente se resume a uma questão de opinião. Espero que todas as funções que sejam manifestamente espaciais, ou seja, elas operem em um vetor, varredura, topologia, superfície 3D etc., levem o prefixo ST_. Nunca me ocorreu perguntar se esse era o uso apropriado, com base em uma especificação ou não. Embora a interoperabilidade seja importante e desejável, eu certamente não gostaria que o Postgis fosse retido implementando apenas funções na especificação SQL / MM. E acho que usar outro prefixo causaria muita confusão.
John Powell

Não entendo por que minha pergunta foi colocada em espera por ser "baseada em opiniões". Minha pergunta é explicitamente sobre se é baseada em opiniões ou se há algum aspecto do padrão que estou ignorando que torna essa decisão baseada em fatos.
Brideau

Desculpas, acabei de reler sua pergunta e há de fato uma pergunta clara e sem opinião. Meu 2c é que, se for explicitamente espacial, ele recebe um ST_, independentemente de estar nos padrões ou não. Eu votei para reabrir.
John Powell

Para mim, é baseado em opinião. O padrão SQL / MM não pode negar que os desenvolvedores criem suas próprias funções com o prefixo ST_, se quiserem, mesmo funções não espaciais. No entanto, os desenvolvedores podem optar por fazê-lo de outra maneira. Como comparação, o SpatiaLite possui muitas funções espaciais, mas não SQL / MM, que possuem sinônimos ST_, outras que não possuem gaia-gis.it/gaia-sins/spatialite-sql-latest.html .
User30184 4/0418

Se o SQL / MM pode ou não forçar um desenvolvedor a fazer algo não é a pergunta que estou fazendo. Estou perguntando sobre o que o próprio padrão recomenda. O padrão tem 1500 páginas, e eu não li todas as linhas, por isso estou perguntando à comunidade aqui - alguns dos quais ajudam a escrevê-lo e padrões relacionados - o que é recomendado, ou talvez se adia essas decisões para outro padrão ou optou explicitamente por não abordar isso. Essas são solicitações baseadas em fatos.
Brideau

Respostas:


1

A especificação OpenSpatial diz várias coisas sobre isso,

Ao integrar esse SQL ao SQL / MM, o prefixo de nome do tipo " ST_" deve ser usado conforme apropriado.

E,

Os nomes de classe no SQL / MM carregam um ST_prefixo " ". Isso é opcional e as implementações podem optar por descartar esse prefixo, como já foi feito em vários locais deste padrão.

Deste comitê Projeto de ISO / IEC CD13249-3 ed 5

Esta parte da ISO / IEC 13249 usa o prefixo ST_para o tipo definido pelo usuário, atributo, rotinável invocado por SQL e nomes de exibição. Esta parte da ISO / IEC 13249 usa o prefixo ' ST_Private' para nomes de determinados atributos. O uso de ' ST_Private' indica que o atributo não é para uso público.

Então aqui está o que temos,

  • SQL / MM sugere usar o prefixo.
  • SQL / MM diz que o prefixo é opcional.
  • ISO também usa o ST_prefixo.

Eu diria isso,

  • O uso de ST_deve ser considerado como palavras-chave não reservadas aos usuários finais. Realmente não há razão para criar funções de usuário final com esse prefixo. Você está melhor apenas usando STx_. Conhecemos pelo menos dois órgãos que publicaram com este prefixo sugestões (OpenSpatial) SQL / MM e ISO. Além disso, muitos símbolos do RDBMS poluem com esse prefixo.

Pode haver mais na história, mas não consigo encontrar mais informações contemporâneas sobre isso.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.