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

11

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

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

Примеры:

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

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

Джордж Сильва
источник
8
Возможное объяснение: числовой идентификатор занимает гораздо меньше байтов, чем нечисловой идентификатор. Это имеет еще большее значение, когда вы начинаете связывать разные таблицы, в которых хранится копия идентификатора.
johanvdw
+1 Хороший вопрос, я не думаю, что NoSQL требует цифровых клавиш.
Кирк Куйкендалл
tinyurl.com/6xrtk2l
CaptDragon
@cap Это немного глупо (и вы уже разместили эту ссылку).
whuber

Ответы:

6

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

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

DEWright
источник
3
Это хорошее объяснение эффективности числового идентификатора. Но я думаю, что @ Джордж исследует более глубоко, чем это. Технически, СУРБД не нужно, чтобы их идентификаторы были числовыми, так зачем же ГИС?
whuber
1
Проблема здесь не в производительности. Не обнуляемый уникальный ключ сделает это. Но почему он должен быть числовым? Как только я услышал или прочитал, что он должен быть числовым, потому что он использует этот ключ для управления рендерингом ... это было в Моделировании нашего мира из ESRI?
Джордж Сильва
2
Потому что ГИС не является СУБД, хотя она может использовать ее. ГИС обычно имеет некоторые правила и предположения, такие как предположение, что первичным ключом будет индексированное целое число или GUID, для обеспечения производительности и здравого смысла кодирования.
blah238
1
хорошо, но зачем считать цифрой? почему мы не можем выбрать наш ключ при создании слоя?
Джордж Сильва
1
Я предполагаю, что основная причина заключается в том, что эти предположения делают работу по написанию кода, который делает работу ГИС-пакета намного, намного проще.
blah238
4

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

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

geographika
источник
4

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

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

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

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

MerseyViking
источник
OpenStreetMap является одним примером проекта , который нуждается в более , чем 32-битных целых чисел. Они используют bigintдля своих первичных ключей.
Майк Т
Для путей / узлов, да. Но оригинальный вопрос был о слоях в ГИС.
MerseyViking
OpenStreetMap хранит ГИС-слои.
Джордж Сильва
OSM просто хранит пути и узлы, которые имеют теги ключ / значение. Это зависит от системы представления (например, OpenLayers) и рендеринга (например, Mapnik, Osmarender), чтобы определить свое представление о слоях на основе этих тегов или чего-то еще. Но Майк прав, он использует bigints для первичных ключей всех своих таблиц.
MerseyViking
+1 за упоминание о конвенции. Это соглашение, потому что оно соответствует лучшей производительности.
CaptDragon
3

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

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

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

Майк Т
источник
+1 Хорошо сказано. В качестве еще одного доказательства того, что это ограничение программирования, отметим, что ESRI не требовал (или не использовал) никаких полей внутренних идентификаторов в ArcView до выхода ArcGIS 8.x. Старый ArcView был способен ко всем операциям с базой данных, которые выполняет ArcGIS (и фактически был быстрее во многих из них).
whuber
2

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

Брэд Несом
источник
Я думаю, что операции ГИС могут иметь какое-то отношение к этому, на самом деле. пересекаются, (пространственные) объединения, различия и т. д. Кто-нибудь может подтвердить или представить это более подробно?
Джордж Сильва
Посмотрите, как один класс пространственных объектов SDE фактически хранится в базе данных, такой как Oracle. Существует одна таблица для атрибутов, одна таблица для геометрии, одна таблица для пространственного индекса, одна или несколько таблиц для индексов атрибутов и т. Д. Если бы ESRI должен был поддерживать каждую кодировку кодовой страницы / символа для строки PKEY, мы бы все по-прежнему на ArcView 3.x.
blah238
@ George - как отметил blah238. ГИС-приложений очень мало, которые используют один файл для хранения обеих (всех) данных. Который может состоять из координат, мер, атрибутов, правил, отношений и многого другого в зависимости от пакета. Это больше связано с возможностью отслеживания того, какая пространственная строка идет с какой строкой атрибута, какой строкой сети и так далее, и так далее.
Брэд Несом
1
Извините, бла-238, я действительно не думаю, что количество кода было решающим в этом вопросе. Enconding не имеет ничего общего с этим. База данных выполнит «математику» и решит, равны ли последовательности символов или нет, следовательно, применяя PKEY. Это не на программном уровне. @Brad Nesom: это также имеет смысл. Но в Oracle и PostGIS вы можете хранить все свои атрибуты в одной таблице. Я согласен, что шейп-файлам нужен страшный ObjectID ... и что, возможно, установило стандарт?
Георгий Сильва
@ Джордж Шейп-файлы не нужны и, как правило, не используют ObjectID. Это поле OID было введено в ArcGIS 8. Поэтому я сомневаюсь, что шейп-файлы имеют какое-либо отношение к этому вопросу.
whuber