ほとんどのGISパッケージに数値IDが必要なのはなぜですか？

これは簡単ですが、物議を醸す可能性のある質問です。なぜ（すべてではないにしても）ほとんどのGISパッケージで、決定されたレイヤーにNULL不可の一意の数値識別子が必要なのはなぜですか？

自然なキーではなく、このような代理キーが必要なのはなぜですか？

例：

• ArcGISはOBJECTID（またはGlobalID）を実施します

• QGISは、数値IDを持たないレイヤーをロードしません。

最適化されたインデックス可能なフィールドが必要だからです。文字列フィールドに何度もインデックスを作成するには、より多くのオーバーヘッドが必要になり、最終的にはそれほど効率的ではありません。

ESRIは、SDEの世界でGUIDフィールドである「GLOBALID」を実際にサポートしているため、これは32文字のフィールドですが、パフォーマンスを向上させるためにインデックスが付けられています。

レイヤーへのレコードの追加を開始する場合、ユーザーがディスクに書き込む直前に新しい機能ごとに一意の英数字コードを入力することに頼ることができます。

..または、単純な自動インクリメント整数フィールドを実装できます。

多くの人が示唆しているように、それは利便性の問題です。しかし、おそらくもっと深く、それは慣習です。

プログラマーとしての最初の本能は、レイヤーIDに数値キーを使用することです。なぜなら、それが常に行われている方法だからです。確かに、少なくとも意識レベルでは、他の方法でそれを行う必要があることさえ、私には思いつかないかもしれません。もちろん、整数を使用しない技術的な理由がある場合、たとえば32ビットに格納できるよりも多くのレイヤーが存在する可能性がある場合（非常にありそうもない命題！）、またはビジネス上の理由がある場合は、その後、代替案が検討されます。

数値キーに関するアルゴリズム上の考慮事項もあります。並べ替え、および並べ替えられた値のリストの検索は、文字列や複雑なオブジェクトのリストであっても、最終的には2つの数値の比較になります。それらはハッシュ関数で単に数字に変わるだけです。とはいえ、現代のコンピューターでは、たとえば100個または1000個ものアイテムのリストを検索することは、高度に最適化されたアルゴリズムを使用する場合と同じくらい、ブルートフォースアプローチを使用するのが普通です。GISのレイヤーの場合、1000以上の複雑なマップでさえ見ることができず、たとえそうだとしても、他の関連する計算は、最適化による小さなゲインよりも桁違いに長くかかります短いリストの検索。

整数キーはプログラマーにとって「理にかなっている」だけであり、Bradが言うように、非数値キーの使用にはさらに努力が必要です。コードを増やすのではなく、精神的な努力を重ねるのかもしれません。私たちは習慣の怠け者です。また、GISのレイヤーのようなものを一意に識別するキーは、ユーザーから「隠されている」と見なされ、ユーザーが混乱しないようにし、一意性に依存するコードを破壊します（DB UNIQUEキーワードにもかかわらず）。ユーザーに十分なロープを与えると、遅かれ早かれ誰かがそれでハングアップするからです。ユーザーが編集可能なフィールドに必ず一意性を強制しますが、基になるシステムはそのキーが一意であり、改ざんされていないことを前提とする必要があります。

この質問は、ジオデータベース側の物事を開発する人（私のような人）にとって紛らわしい質問です。

PostgreSQLは異なるデータ型の複合プライマリキーを持つテーブルを定義できるため、データベースストレージの制限ではありませんが、これらのテーブルはQGISなどのプログラムにロードできません。関連する歴史的なメモでは、PostgreSQLは、OID列を内部キーとして要求していましたが、これも32ビット整数でした。これは、バージョン7.2まで必要でした。

32ビット整数IDの要件は、実際にはプログラミングの制限です。一連のレコードへのインデックスを固定データ型（32ビット整数）として持つ方がはるかに簡単であり、これがそのレコードのプライマリキーでもあると便利です。プログラムで複合主キーを許可し、複数またはさまざまなデータ型に基づいて一意のレコードを取得することは、より困難です。ただし、PostgreSQLのOIDと同様に、この制限は開発時間で克服できます。QGISの場合、[現在] 5年前のバグはいつか解決されるかもしれません（このトピックに関する最近の議論があります）。

ESRIおよびその他のGISソフトウェアでは、フィーチャクラスまたはデータセットを作成するフォルダーまたはファイルのセットが一般的です。
例：arcinfoカバレッジ、シェープファイル、ファイルジオデータベース。
これらのファイルの「セット」は、多くのGIS機能を可能にするために、ソフトウェアによって「結合」される必要があります。
Attrubuteテーブル、ネットワーク、トポロジコントロール。
それがOIDの目的であり、それをNull不可、非表示、ソフトウェア制御にする理由でもあります。