Pourquoi la plupart des packages SIG ont-ils besoin d'un identifiant numérique?

Il s'agit d'une question simple mais peut-être controversée: pourquoi la plupart des progiciels SIG (sinon tous) nécessitent-ils qu'une couche déterminée ait un identifiant numérique unique non annulable ?

Pourquoi est-il nécessaire d'avoir une telle clé de substitution au lieu d'une clé naturelle?

Exemples:

• ArcGIS applique OBJECTID (ou un GlobalID)

• QGIS ne charge pas les couches lorsqu'elles n'ont pas d'identifiant numérique.

Parce qu'ils ont besoin d'un champ indexable optimisé. Pour indexer un champ de chaîne encore et encore, il faudrait plus de surcharge et à la fin n'est pas aussi efficace.

ESRI prend en charge dans le monde SDE le «GLOBALID» qui est un champ GUID, il s'agit donc d'un champ de 32 caractères mais est toujours indexé pour augmenter les performances.

Si vous commencez à ajouter des enregistrements à une couche, vous pouvez compter sur un utilisateur saisissant un code alphanumérique unique pour chaque nouvelle fonctionnalité juste avant de l'écrire sur le disque.

..ou vous pouvez implémenter un simple champ entier à auto-incrémentation.

Comme beaucoup de gens l'ont suggéré, c'est une question de commodité; mais peut-être plus profondément, c'est la convention.

En tant que programmeur, mon premier réflexe serait d'utiliser une clé numérique pour un ID de couche car c'est ainsi que cela a toujours été fait. En effet, il ne m'est même pas venu à l'esprit, au moins sur un plan conscient, que je doive procéder autrement. Bien sûr, s'il y a une raison technique de ne pas utiliser d'entiers, dites s'il y a une possibilité qu'il y ait plus de couches que ce qui peut être stocké en 32 bits (une proposition très improbable!), Ou s'il y a une raison commerciale pour cela, alors des alternatives seraient envisagées.

Il y a aussi des considérations algorithmiques avec les touches numériques. Le tri et la recherche d'une liste de valeurs triées se résument finalement à une comparaison entre deux nombres, même s'il s'agit d'une liste de chaînes ou d'objets complexes; ils sont simplement transformés en nombres avec une fonction de hachage . Cela dit, sur les ordinateurs modernes, la recherche d'une liste de 100 ou même 1000 éléments est généralement aussi rapide avec une approche par force brute qu'avec un algorithme hautement optimisé. Dans le cas des couches dans un SIG, je ne vois même pas la plus complexe des cartes ayant plus de 1000 ou plus, et même si c'était le cas, les autres calculs associés prendraient des ordres de grandeur plus longs que tout petit gain d'un optimisé recherche d'une liste restreinte.

Les clés entières "ont tout simplement du sens" pour un programmeur, et comme le dit Brad, l'utilisation de touches non numériques demande plus d'efforts. Peut-être pas plus de code, mais plus d'effort mental, et nous sommes des créatures paresseuses d'habitude. De plus, la clé qui identifie de manière unique quelque chose comme une couche dans un SIG est considérée comme "cachée" par l'utilisateur, pour s'assurer qu'il ne s'en occupe pas et ne casse pas le code qui repose sur son unicité (malgré les mots-clés DB UNIQUE). Parce que si vous donnez suffisamment de corde à un utilisateur, tôt ou tard, quelqu'un se pendre avec. Bien sûr, imposez l' unicité sur un champ modifiable par l'utilisateur, mais le système sous-jacent doit supposer que sa clé est unique et non altérée.

Cette question a été déroutante pour les personnes (comme moi) qui développent le côté géodatabase des choses.

Ce n'est pas une limitation du stockage de base de données, car PostgreSQL peut définir des tables avec des CLÉS PRIMAIRES composites de différents types de données, cependant, ces tables ne peuvent pas être chargées dans des programmes comme QGIS. Sur une note historique connexe, PostgreSQL exigeait auparavant une colonne OID comme clé interne, qui était également un entier 32 bits. Cela était nécessaire jusqu'à la version 7.2 .

L'exigence d'ID entier 32 bits est vraiment une limitation de programmation. Il est beaucoup plus simple d'avoir un index vers un ensemble d'enregistrements en tant que type de données fixe (entier 32 bits), et il est pratique que ce soit également la CLÉ PRIMAIRE pour cet enregistrement. Il est plus difficile de permettre à un programme d'autoriser une clé primaire composite et de récupérer un enregistrement unique basé sur des types de données multiples et / ou variables. Cependant, comme l'OID de PostgreSQL, cette limitation peut être surmontée avec le temps de développement. Pour QGIS, le bogue de [maintenant] âgé de 5 ans pourrait être résolu un jour (voici une discussion récente sur le sujet).

Dans ESRI et d'autres logiciels SIG, il est courant d'avoir un dossier ou un ensemble de fichiers qui se produisent sur une classe d'entités ou un ensemble de données.
par exemple couverture arcinfo, fichier de formes, géodatabase fichier.
Ces "ensembles" de fichiers doivent être "joints" par le logiciel pour permettre de nombreuses fonctions SIG.
Tables d'attrubution, réseau, contrôles topologiques.
C'est le but de l'OID et aussi la raison pour laquelle il est non nul, caché, contrôlé par logiciel.