Чому для більшості пакетів GIS потрібен числовий ідентифікатор?

Це просте, але можливо суперечливе запитання: чому більшість (якщо не всі) GIS-пакетів вимагають, щоб певний рівень мав унікальний ненульовий числовий ідентифікатор?

Чому існує необхідність у такому сурогатному ключі замість природного?

Приклади:

• ArcGIS застосовує OBJECTID (або GlobalID)

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

Тому що вони повинні мати оптимізоване поле, що індексується. Для індексації рядкового поля знову і знову знадобиться більше накладних витрат і, врешті-решт, це не так ефективно.

ESRI насправді підтримує у світі SDE 'GLOBALID', що є GUID-полем, тому це 32-метрове поле, але все ще індексується для підвищення продуктивності.

Якщо ви почнете додавати записи до шару, ви можете розраховувати на те, що користувач введе унікальний буквено-цифровий код для кожної нової функції безпосередньо перед записом на диск ..

..або ви могли реалізувати просте ціле поле для автоматичного збільшення.

Як багато людей припустили, це питання зручності; але, можливо, глибше, це конвенція.

Як програміст, моїм першим інстинктом було б використовувати цифровий ключ для ідентифікатора шару, тому що це було завжди. Дійсно, мені може навіть не прийти в голову, принаймні, на свідомому рівні, що я повинен це робити будь-яким іншим способом. Звичайно, якщо є технічна причина не використовувати цілі числа, скажіть, чи існує можливість наявності більше шарів, ніж можна зберегти в 32-бітних (дуже малоймовірна пропозиція!), Або якщо для цього є бізнес-причина, тоді альтернативи будуть розглядатися.

Існують також алгоритмічні міркування з цифровими клавішами. Сортування та пошук списку відсортованих значень зрештою зводиться до порівняння двох чисел, навіть якщо це список рядків або складних об'єктів; вони просто перетворюються на числа з функцією хешування . Зауваживши, що на сучасних комп’ютерах пошук списку 100 або навіть 1000 предметів, як правило, настільки ж швидкий при грубому підході, як і при високо оптимізованому алгоритмі. У випадку шарів в ГІС я не бачу навіть найскладніших карт, що мають більше 1000 або близько того, і навіть якби це було, інші пов'язані з ним обчислення займуть порядків більше, ніж будь-який невеликий приріст від оптимізованого пошук короткого списку.

Цілі клавіші "просто мають сенс" для програміста, і, як каже Бред, докладено більше зусиль у використанні нечислових ключів. Можливо, не більше коду, але більше розумових зусиль, і ми ліниві істоти за звичкою. Також ключ, що однозначно ідентифікує щось на кшталт шару в ГІС, вважається "прихованим" від користувача, щоб переконатися, що вони з ним не возиться і порушують код, який покладається на його унікальність (незважаючи на ключові слова DB UNIQUE). Тому що якщо ви дасте користувачеві достатньо мотузки, рано чи пізно хтось повіситься на нього. У будь-якому разі застосовувати унікальність у користувальницькому полі, але система, що лежить в основі, повинна вважати, що її ключ є унікальним і не має змоги.

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

Це не обмеження для зберігання баз даних, оскільки PostgreSQL може визначати таблиці із складеними ОСНОВНИМИ КЛЮЧАми різних типів даних, однак ці таблиці не можна завантажувати в такі програми, як QGIS. У відповідній історичній примітці PostgreSQL використовував вимогу стовпця OID як внутрішнього ключа, який також був 32-бітним цілим числом. Це потрібно було до версії 7.2 .

32-розрядна цілочисельна вимога ID - це дійсно обмеження програмування. Набагато простіше мати індекс до набору записів як фіксованого типу даних (32-бітове ціле число), і для цього зручно також бути ПЕРВИЧНИЙ КЛЮЧ для цього запису. Складніше зробити так, щоб програма дозволяла складати первинний ключ, а також отримувати унікальний запис на основі декількох та / або різних типів даних. Однак, як і OID PostgreSQL, це обмеження можна подолати з часом розробки. Що стосується QGIS, [тепер] 5-річна помилка може бути вирішена якось днями (ось деякі останні дискусії з цієї теми).

В ESRI та іншому програмному забезпеченні GIS прийнято мати папку або набір файлів, які створюються в класах функцій або наборі даних.
наприклад, покриття arcinfo, форм-файл, база даних геоданих.
Ці "набори" файлів повинні бути "об'єднані" програмним забезпеченням для забезпечення багатьох функцій ГІС.
Напружують таблиці, мережу, топологічні елементи управління.
Це мета OID, а також причина для того, щоб зробити його нерегульованим, прихованим, керованим програмним забезпеченням.