Perché la maggior parte dei pacchetti GIS necessita di un ID numerico?

Questa è una domanda semplice ma forse controversa: perché la maggior parte (se non tutti) i pacchetti GIS richiedono che un determinato livello abbia un identificatore numerico non nulla univoco?

Perché c'è bisogno di una chiave così surrogata anziché naturale?

Esempi:

• ArcGIS applica OBJECTID (o un GlobalID)

• QGIS non carica i livelli quando non dispongono di un ID numerico.

Perché devono avere un campo indicizzabile ottimizzato. Indicizzare più volte un campo stringa richiederebbe un maggior sovraccarico e alla fine non è altrettanto efficiente.

ESRI in realtà supporta nel mondo SDE il 'GLOBALID' che è un campo GUID, quindi questo è un campo 32char ma è ancora indicizzato per aumentare le prestazioni.

Se inizi ad aggiungere record a un livello, puoi fare affidamento su un utente che immette un codice alfanumerico univoco per ogni nuova funzione prima di scriverlo sul disco.

..o potresti implementare un semplice campo intero autoincrementante.

Come molte persone hanno suggerito, è una questione di convenienza; ma forse più profondamente, è una convenzione.

Come programmatore, il mio primo istinto sarebbe quello di usare un tasto numerico per un ID di livello perché è così che è sempre stato fatto. In effetti, forse non mi viene nemmeno in mente, almeno a livello cosciente, che dovrei farlo in qualsiasi altro modo. Naturalmente, se esiste un motivo tecnico per non utilizzare numeri interi, dire se esiste la possibilità che ci siano più livelli di quanti possano essere memorizzati in 32 bit (una proposta molto improbabile!) O se esiste un motivo commerciale per questo, allora sarebbero prese in considerazione alternative.

Ci sono anche considerazioni algoritmiche con i tasti numerici. L'ordinamento e la ricerca di un elenco di valori ordinati alla fine si riduce a un confronto tra due numeri, anche se si tratta di un elenco di stringhe o oggetti complessi; vengono semplicemente trasformati in numeri con una funzione di hashing . Detto questo, sui moderni computer, la ricerca di un elenco di 100 o addirittura 1000 voci è solitamente rapida con un approccio a forza bruta come lo è con un algoritmo altamente ottimizzato. Nel caso di layer in un GIS, non riesco a vedere nemmeno la più complessa delle mappe con più di 1000 o giù di lì, e anche se lo facesse, gli altri calcoli associati prenderebbero ordini di grandezza più lunghi di qualsiasi piccolo guadagno da un ottimizzato ricerca di un breve elenco.

I tasti interi "hanno senso" per un programmatore e, come dice Brad, c'è più impegno nell'uso di tasti non numerici. Forse non più codice, ma più sforzo mentale, e siamo pigre creature dell'abitudine. Inoltre, la chiave che identifica in modo univoco qualcosa come un livello in un GIS è considerata "nascosta" dall'utente, per assicurarsi che non si scherzi con esso e rompere il codice che si basa sulla sua unicità (nonostante le parole chiave DB UNIQUE). Perché se dai a un utente abbastanza corda, prima o poi qualcuno si impiccerà con esso. Applica in modo univoco un campo modificabile dall'utente, ma il sistema sottostante deve assumere che la sua chiave sia unica e non manomessa.

Questa domanda è stata confusa per le persone (come me) che sviluppano il lato geodatabase delle cose.

Non è una limitazione dell'archiviazione del database, poiché PostgreSQL può definire tabelle con CHIAVI PRIMARIE composte di diversi tipi di dati, tuttavia queste tabelle non possono essere caricate in programmi come QGIS. In una nota storica correlata, PostgreSQL richiedeva una colonna OID come chiave interna, che era anche un numero intero a 32 bit. Ciò era necessario fino alla versione 7.2 .

Il requisito dell'ID intero a 32 bit è in realtà un limite di programmazione. È molto più semplice avere un indice su un set di record come tipo di dati fisso (numero intero a 32 bit), ed è conveniente per questo essere anche il PRIMARY KEY per quel record. È più difficile fare in modo che un programma consenta una chiave primaria composita e che recuperi un record univoco basato su più e / o diversi tipi di dati. Tuttavia, come l'OID di PostgreSQL, questa limitazione può essere superata con i tempi di sviluppo. Per QGIS, il bug [ora] di 5 anni potrebbe essere risolto un giorno (ecco alcune discussioni recenti sull'argomento).

In ESRI e in altri software GIS, è comune avere una cartella o un set di file che compongono la classe di funzionalità o il set di dati.
ad es. copertura arcinfo, shapefile, file geodatabase.
Questi "set" di file devono essere "uniti" dal software per consentire molte funzioni GIS.
Attrubute tabelle, rete, controlli topologici.
Questo è lo scopo dell'OID e anche il motivo per renderlo non annullabile, nascosto, controllato dal software.