Почему большинству пакетов ГИС нужен числовой идентификатор?

Это простой, но, возможно, противоречивый вопрос: почему большинство (если не все) ГИС-пакетов требуют, чтобы определенный слой имел уникальный числовой идентификатор, который не может иметь значение NULL ?

Почему нужен такой суррогатный ключ вместо естественного?

Примеры:

• ArcGIS применяет OBJECTID (или GlobalID)

• QGIS не загружает слои, если у них нет числового идентификатора.

Потому что им нужно иметь оптимизированное индексируемое поле. Чтобы индексировать строковое поле снова и снова, потребовалось бы больше накладных расходов, и, в конце концов, это не так эффективно.

ESRI на самом деле поддерживает в мире SDE «GLOBALID», который представляет собой поле GUID, поэтому это поле с 32 символами, но все же индексируется для повышения производительности.

Если вы начнете добавлять записи в слой, вы можете полагаться на то, что пользователь вводит уникальный буквенно-цифровой код для каждой новой функции непосредственно перед записью на диск.

... или вы можете реализовать простое автоинкрементное целочисленное поле.

Как полагают многие, это вопрос удобства; но, возможно, более глубоко, это соглашение.

Как программист, мой первый инстинкт - использовать числовой ключ для идентификатора слоя, потому что так было всегда. Действительно, мне может даже не прийти в голову, по крайней мере на сознательном уровне, что я должен сделать это любым другим способом. Конечно, если есть техническая причина не использовать целые числа, скажем, есть ли вероятность того, что слоев будет больше, чем может быть сохранено в 32-битном формате (очень маловероятное предложение!), Или если для этого есть бизнес-причина, тогда будут рассмотрены альтернативы.

Есть также алгоритмические соображения с числовыми ключами. Сортировка и поиск в списке отсортированных значений в конечном итоге сводятся к сравнению двух чисел, даже если это список строк или сложных объектов; они просто превращаются в числа с функцией хеширования . Сказав это, на современных компьютерах поиск списка, скажем, 100 или даже 1000 элементов обычно такой же быстрый, как и в случае с грубой силой, с высоко оптимизированным алгоритмом. В случае слоев в ГИС я не вижу даже самых сложных карт, имеющих более 1000 или около того, и даже если бы это было так, другие связанные вычисления потребовали бы на порядки больше, чем любой небольшой выигрыш от оптимизированного поиск по короткому списку.

Целочисленные ключи «просто имеют смысл» для программиста, и, как говорит Брэд, в использовании нечисловых ключей требуется больше усилий. Может быть, не больше кода, но больше умственных усилий, и мы ленивые существа по привычке. Кроме того, ключ, который однозначно идентифицирует что-то вроде слоя в ГИС, считается «скрытым» от пользователя, чтобы он не связывался с ним и не нарушал код, основанный на его уникальности (несмотря на ключевые слова DB UNIQUE). Потому что, если вы дадите пользователю достаточно веревки, рано или поздно кто-то повесится с ним. Безусловно, применяйте уникальность в редактируемом пользователем поле, но базовая система должна предполагать, что ее ключ уникален и не изменен.

Этот вопрос сбивает с толку людей (таких как я), которые разрабатывают сторону базы геоданных.

Это не ограничение хранения базы данных, поскольку PostgreSQL может определять таблицы с составными PRIMARY KEYS разных типов данных, однако эти таблицы не могут быть загружены в такие программы, как QGIS. В соответствующей исторической заметке PostgreSQL требовал в качестве внутреннего ключа столбец OID , который также был 32-разрядным целым числом. Это требовалось до версии 7.2 .

Требование 32-битного целочисленного идентификатора на самом деле является программным ограничением. Намного проще иметь индекс для набора записей в виде фиксированного типа данных (32-разрядное целое число), и для него также удобно быть ПЕРВИЧНЫМ КЛЮЧОМ для этой записи. Более сложно заставить программу разрешить составной первичный ключ и получить для нее уникальную запись, основанную на множественных и / или различных типах данных. Однако, как и OID в PostgreSQL, это ограничение можно преодолеть со временем разработки. Для QGIS [сейчас] 5-летняя ошибка может быть решена когда-нибудь (вот недавнее обсуждение этой темы).

В ESRI и другом программном обеспечении ГИС обычно имеется папка или набор файлов, которые создаются в классе объектов или наборе данных.
например, покрытие arcinfo, шейп-файл, файловая база геоданных.
Эти «наборы» файлов должны быть «объединены» программным обеспечением для обеспечения многих функций ГИС.
Аттрубутные таблицы, сеть, топологический контроль.
Это цель OID, а также причина сделать его необнуляемым, скрытым, управляемым программным обеспечением.