Por que a maioria dos pacotes GIS precisa de um ID numérico?

Esta é uma pergunta simples, mas possivelmente controversa: por que a maioria (senão todos) dos pacotes GIS exigem que uma determinada camada tenha um identificador numérico exclusivo e não nulo ?

Por que existe a necessidade de uma chave substituta em vez de uma chave natural?

Exemplos:

• O ArcGIS aplica OBJECTID (ou um GlobalID)

• O QGIS não carrega camadas quando elas não têm um ID numérico.

Porque eles precisam ter um campo indexável otimizado. Para indexar um campo de string repetidamente, seria necessário mais sobrecarga e, no final, não é tão eficiente.

A ESRI realmente suporta no mundo da SDE o 'GLOBALID', que é um campo GUID, portanto esse é um campo de 32 caracteres, mas ainda é indexado para aumentar o desempenho.

Se você começar a adicionar registros a uma camada, poderá confiar em um usuário digitando um código alfanumérico exclusivo para cada novo recurso antes de gravá-lo no disco.

..ou você pode implementar um campo inteiro simples de incremento automático.

Como muitas pessoas sugeriram, é uma questão de conveniência; mas talvez mais profundamente, é convenção.

Como programador, meu primeiro instinto seria usar uma tecla numérica para um ID de camada, porque é assim que sempre foi feito. De fato, pode nem me ocorrer, pelo menos em nível consciente, que eu deva fazê-lo de outra maneira. É claro que, se houver uma razão técnica para não usar números inteiros, diga se existe a possibilidade de haver mais camadas do que as que podem ser armazenadas em 32 bits (uma proposta muito improvável!) Ou se existe uma razão comercial para isso, então alternativas seriam consideradas.

Há também considerações algorítmicas com teclas numéricas. A classificação e a pesquisa de uma lista de valores classificados acabam resumindo-se a uma comparação entre dois números, mesmo que seja uma lista de cadeias ou objetos complexos; eles simplesmente se transformam em números com uma função de hash . Dito isto, em computadores modernos, pesquisar uma lista de, digamos, 100 ou até 1000 itens é geralmente tão rápido com uma abordagem de força bruta quanto com um algoritmo altamente otimizado. No caso de camadas em um GIS, não consigo ver nem o mais complexo dos mapas com mais de 1000, e mesmo que o fizesse, os outros cálculos associados levariam ordens de magnitude mais longas do que qualquer pequeno ganho de um otimizado. pesquisa de uma lista curta.

Teclas inteiras "fazem sentido" para um programador e, como Brad diz, há mais esforço no uso de teclas não numéricas. Talvez não mais código, mas mais esforço mental, e somos criaturas preguiçosas de hábito. Além disso, a chave que identifica exclusivamente algo como uma camada em um GIS é considerada "oculta" do usuário, para garantir que eles não mexam com ela e quebrem o código que depende de sua exclusividade (não obstante as palavras-chave do DB UNIQUE). Porque se você der corda suficiente a um usuário, mais cedo ou mais tarde alguém se enforcará com ela. De qualquer modo, imponha exclusividade em um campo editável pelo usuário, mas o sistema subjacente deve assumir que sua chave é única e sem alterações.

Essa questão tem sido confusa para pessoas (como eu) que desenvolvem o lado do geodatabase.

Não é uma limitação do armazenamento do banco de dados, pois o PostgreSQL pode definir tabelas com PRIMARY KEYS compostas de diferentes tipos de dados; no entanto, essas tabelas não podem ser carregadas em programas como o QGIS. Em uma nota histórica relacionada, o PostgreSQL exigia uma coluna OID como uma chave interna, que também era um número inteiro de 32 bits. Isso foi necessário até a versão 7.2 .

O requisito de ID inteiro de 32 bits é realmente uma limitação de programação. É muito mais simples ter um índice para um conjunto de registros como um tipo de dados fixo (número inteiro de 32 bits), e é conveniente que essa também seja a PRIMARY KEY para esse registro. É mais desafiador tornar um programa permitir uma chave primária composta e recuperar um registro exclusivo com base em vários e / ou tipos de dados variáveis. No entanto, como o OID do PostgreSQL, essa limitação pode ser superada com o tempo de desenvolvimento. Para o QGIS, o bug de 5 anos [agora] pode ser resolvido algum dia (aqui está uma discussão recente sobre o assunto).

No ESRI e em outros softwares GIS, é comum ter uma pasta ou um conjunto de arquivos que compõem a classe de recurso ou o conjunto de dados.
por exemplo, cobertura arcinfo, shapefile, geodatabase de arquivo.
Esses "conjuntos" de arquivos precisam ser "unidos" pelo software para permitir muitas funções GIS.
Tabelas de atribuição, rede, controles topológicos.
Esse é o objetivo do OID e também o motivo para torná-lo não anulável, oculto e controlado por software.