¿Por qué la mayoría de los paquetes SIG necesitan una identificación numérica?

Esta es una pregunta simple pero posiblemente controvertida: ¿por qué la mayoría (si no todos) los paquetes de SIG requieren que una capa determinada tenga un identificador numérico único no anulable ?

¿Por qué existe la necesidad de una clave sustituta en lugar de una clave natural?

Ejemplos:

• ArcGIS aplica OBJECTID (o un GlobalID)

• QGIS no carga capas cuando no tienen una identificación numérica.

Porque necesitan tener un campo indexable optimizado. Para indexar un campo de cadena una y otra vez requeriría más sobrecarga y al final no es tan eficiente.

En realidad, ESRI admite en el mundo SDE el 'GLOBALID' que es un campo GUID, por lo que este es un campo 32char pero aún está indexado para aumentar el rendimiento.

Si comienza a agregar registros a una capa, puede confiar en que un usuario ingrese un código alfanumérico único para cada nueva característica justo antes de escribirla en el disco.

..o podría implementar un campo entero simple de autoincremento.

Como muchas personas han sugerido, es una cuestión de conveniencia; pero quizás más profundamente, es una convención.

Como programador, mi primer instinto sería usar una clave numérica para una ID de capa porque esa es la forma en que siempre se ha hecho. De hecho, puede que ni siquiera se me ocurra, al menos en un nivel consciente, que debería hacerlo de otra manera. Por supuesto, si hay una razón técnica para no usar números enteros, diga si existe la posibilidad de que haya más capas de las que se pueden almacenar en 32 bits (¡una propuesta muy poco probable!), O si hay una razón comercial para ello, entonces se considerarían alternativas.

También hay consideraciones algorítmicas con las teclas numéricas. La clasificación y la búsqueda de una lista de valores ordenados se reduce en última instancia a una comparación entre dos números, incluso si se trata de una lista de cadenas u objetos complejos; simplemente se convierten en números con una función hash . Dicho esto, en las computadoras modernas, buscar una lista de, digamos, 100 o incluso 1000 elementos suele ser tan rápido con un enfoque de fuerza bruta como con un algoritmo altamente optimizado. En el caso de las capas en un SIG, no puedo ver ni siquiera el más complejo de los mapas que tienen más de 1000, e incluso si lo hiciera, los otros cálculos asociados tomarían órdenes de magnitud más que cualquier ganancia pequeña de un optimizado búsqueda de una lista corta

Las teclas enteras "simplemente tienen sentido" para un programador, y como dice Brad, hay más esfuerzo en el uso de teclas no numéricas. Tal vez no más código, sino más esfuerzo mental, y somos criaturas vagas de hábito. Además, la clave que identifica de forma única algo como una capa en un SIG se considera "oculta" para el usuario, para asegurarse de que no se meta con ella y rompa el código que se basa en su unicidad (a pesar de las palabras clave DB UNIQUE). Porque si le das suficiente cuerda a un usuario, tarde o temprano alguien se ahorcará con ella. Por supuesto, imponga la unicidad en un campo editable por el usuario, pero el sistema subyacente debe asumir que su clave es única y sin restricciones.

Esta pregunta ha sido confusa para las personas (como yo) que desarrollan el lado de la geodatabase de las cosas.

No es una limitación del almacenamiento de la base de datos, ya que PostgreSQL puede definir tablas con CLAVES PRIMARIAS compuestas de diferentes tipos de datos, sin embargo, estas tablas no se pueden cargar en programas como QGIS. En una nota histórica relacionada, PostgreSQL solía requerir una columna OID como clave interna, que también era un entero de 32 bits. Esto fue requerido hasta la versión 7.2 .

El requisito de ID de entero de 32 bits es realmente una limitación de programación. Es mucho más simple tener un índice para un conjunto de registros como un tipo de datos fijo (entero de 32 bits), y es conveniente que esto también sea la CLAVE PRIMARIA para ese registro. Es más desafiante hacer que un programa permita una clave primaria compuesta y que recupere un registro único basado en múltiples y / o diferentes tipos de datos. Sin embargo, al igual que el OID de PostgreSQL, esta limitación se puede superar con el tiempo de desarrollo. Para QGIS, el error de [ahora] 5 años podría resolverse algún día (aquí hay una discusión reciente sobre el tema).

En ESRI y en otro software SIG, es común tener una carpeta o un conjunto de archivos que forman parte de la clase de entidad o conjunto de datos.
por ejemplo, cobertura de arcinfo, shapefile, geodatabase de archivos.
Estos "conjuntos" de archivos deben ser "unidos" por el software para permitir muchas funciones SIG.
Tablas de atributos, red, controles topológicos.
Ese es el propósito del OID y también la razón para hacerlo no anulable, oculto, controlado por software.