대부분의 GIS 패키지에 숫자 ID가 필요한 이유는 무엇입니까?

11

이것은 간단하지만 논란의 여지가있는 질문입니다. 왜 대부분의 GIS 패키지가 결정된 레이어에 고유 한 널 입력 가능 숫자 식별자가 필요합니까?

자연스럽게 대신에 그러한 대리 키가 필요한 이유는 무엇입니까?

예 :

ArcGIS는 OBJECTID (또는 GlobalID)를 시행합니다
QGIS는 숫자 ID가없는 레이어를로드하지 않습니다.

database

— 조지 실바
소스

8

가능한 설명 : 숫자 ID는 숫자가 아닌 ID보다 훨씬 적은 바이트를 차지합니다. 이것은 ID의 사본을 저장하는 다른 테이블을 연결하기 시작할 때 더욱 중요합니다.

— johanvdw

+1 좋은 질문 입니다. NoSQL 에 숫자 키가 필요 하다고 생각하지 않습니다 .

— Kirk Kuykendall

tinyurl.com/6xrtk2l

— CaptDragon

@cap 그것은 약간의 방해입니다 (그리고 당신은 이미 그 링크를 게시했습니다).

— whuber

6

최적화 된 색인 작성 가능 필드가 필요하기 때문입니다. 문자열 필드를 반복해서 색인화하려면 더 많은 오버 헤드가 필요하며 결국에는 효율적이지 않습니다.

ESRI는 실제로 SDE 세계에서 GUID 필드 인 'GLOBALID'를 지원하므로이 필드는 32char 필드이지만 여전히 성능을 향상시키기 위해 색인화됩니다.

— 어리석은
소스

3

숫자 ID의 효율성 이점에 대한 좋은 설명입니다. 그러나 @George는 이것보다 더 깊이 조사하고 있다고 생각합니다. 기술적으로 RDBMS는 식별자가 숫자가 될 필요가 없습니다. 왜 GIS를 사용해야합니까?

— whuber

1

여기서 문제는 성능이 아닙니다. 널 입력 가능하지 않은 고유 키가이를 수행합니다. 그러나 왜 숫자 여야합니까? 내가 그 키를 사용하여 렌더링을 제어하기 때문에 숫자가 필요하다는 말을 들었거나 읽었을 때 ESRI에서 우리의 세계를 모델링 했습니까?

— George Silva

2

GIS는 RDBMS가 아니기 때문에 RDBMS를 사용할 수 있습니다. GIS는 일반적으로 성능 및 코딩 안정성을 위해 기본 키가 색인화 된 정수 또는 GUID라는 가정과 같은 몇 가지 규칙과 가정을 갖습니다.

— blah238

1

그래, 왜 숫자를 가정해야합니까? 레이어를 만들 때 왜 키를 선택할 수 없습니까?

— George Silva

1

주된 이유는 이러한 가정이 GIS 패키지를 훨씬 더 쉽게 작동시키는 코드 작성 작업을 만드는 것이라고 생각합니다.

— blah238

4

레이어에 레코드를 추가하기 시작하면 디스크에 기록하기 직전에 모든 새로운 기능에 대해 고유 한 영숫자 코드를 입력하는 사용자에게 의존 할 수 있습니다 .

.. 또는 간단한 자동 증가 정수 필드를 구현할 수 있습니다.

— 지리
소스

4

많은 사람들이 제안했듯이, 그것은 편의의 문제입니다. 그러나 아마도 더 심오한 것은 컨벤션입니다.

프로그래머로서 필자의 첫 번째 본능은 레이어 ID에 숫자 키를 사용하는 것이 었습니다. 이것이 항상 수행 된 방식이기 때문입니다. 실제로, 적어도 다른 방법으로해야한다는 것은 의식 수준에서 나에게 일어나지 않을 수도 있습니다. 물론 정수를 사용하지 않는 기술적 이유가있는 경우 32 비트에 저장할 수있는 것보다 더 많은 레이어가있을 가능성이 있거나 (매우 가능성이 낮습니다!) 비즈니스상의 이유가있는 경우, 대안이 고려 될 것이다.

숫자 키에 대한 알고리즘 고려 사항도 있습니다. 정렬 된 값 목록을 정렬하고 검색하면 결국 문자열이나 복잡한 객체 목록 인 경우에도 두 숫자를 비교할 수 있습니다. 단지 해싱 함수 로 숫자로 바뀔뿐입니다 . 현대 컴퓨터에서는 100 개 또는 1000 개 항목의 목록을 검색하는 것이 일반적으로 고도로 최적화 된 알고리즘을 사용하는 것처럼 무차별 대입 방식을 사용하는 것만 큼 빠릅니다. GIS의 레이어의 경우 1000 개 이상의 맵이있는 가장 복잡한 맵조차 볼 수 없으며, 그렇게해도 다른 관련 계산은 최적화 된 작은 이익보다 몇 배나 더 오래 걸립니다 짧은 목록 검색.

정수 키는 프로그래머에게 "상당히 의미가 있습니다". Brad가 말했듯이 숫자가 아닌 키를 사용하는 데 더 많은 노력이 있습니다. 어쩌면 더 많은 코드가 아니라 더 많은 정신적 노력이 있고 우리는 게으른 습관의 생물입니다. 또한, GIS에서 레이어와 같은 것을 고유하게 식별하는 키는 사용자로부터 "숨겨진"것으로 간주되어 해당 레이어를 엉망으로 만들지 않고 고유성에 의존하는 코드를 손상시킵니다 (DB UNIQUE 키워드에도 불구하고). 사용자에게 충분한 로프를 주면 조만간 누군가가 로프에 매달릴 수 있기 때문입니다. 항상 사용자 편집 가능 필드에서 고유성을 적용하지만 기본 시스템 은 해당 키가 고유하고 변조되지 않은 것으로 가정 해야합니다 .

— 머지 바이킹
소스

OpenStreetMap에이 이상 32 비트 정수보다 프로젝트 필요의 일례이다. bigint기본 키에 사용 합니다.

— Mike T

방법 / 노드의 경우 예. 그러나 원래 질문은 GIS의 계층에 관한 것이 었습니다.

— MerseyViking

OpenStreetMap은 GIS 레이어를 저장합니다.

— George Silva

OSM은 키 / 값 태그가있는 방식과 노드 만 저장합니다. 이러한 태그 또는 다른 것을 기반으로 레이어의 개념을 결정하는 것은 프리젠 테이션 시스템 (예 : OpenLayers) 및 렌더링 백엔드 (예 : Mapnik, Osmarender)에 달려 있습니다. 그러나 Mike는 맞습니다. bigint모든 테이블의 기본 키에 s를 사용 합니다.

— MerseyViking

컨벤션에 대한 언급으로 +1 더 나은 성능과 같기 때문에 규칙입니다.

— CaptDragon

3

이 질문은 지오 데이터베이스 측면을 개발하는 사람들 (나 같은 사람)에게 혼란스러운 질문이었습니다.

PostgreSQL은 다양한 데이터 유형의 복합 PRIMARY KEYS를 사용하여 테이블을 정의 할 수 있으므로 데이터베이스 스토리지의 제한은 없지만 QGIS와 같은 프로그램에는 이러한 테이블을로드 할 수 없습니다. 관련 기록에서 PostgreSQL 은 32 비트 정수이기도 한 OID 열을 내부 키로 요구했습니다 . 버전 7.2까지 필요했습니다 .

32 비트 정수 ID 요구 사항은 실제로 프로그래밍 제한 사항입니다. 고정 된 데이터 유형 (32 비트 정수)으로 레코드 세트에 대한 색인을 갖는 것이 훨씬 간단하며, 해당 레코드의 기본 키가되는 것이 편리합니다. 프로그램이 복합 기본 키를 허용하고 여러 데이터 유형 및 / 또는 다양한 데이터 유형을 기반으로 고유 한 레코드를 검색하는 것이 더 어렵습니다. 그러나 PostgreSQL의 OID와 마찬가지로이 제한은 개발 시간으로 극복 할 수 있습니다. QGIS의 경우 [현재] 5 년 된 버그 가 언젠가 해결 될 수 있습니다 ( 이 주제에 대한 최근 토론이 있습니다).

— 마이크 T
소스

+1 잘 말했다. 이것이 프로그래밍 제한 사항이라는 추가 증거로 ArcGIS 8.x가 나오기 전에 ESRI가 ArcView의 내부 식별자 필드를 요구하거나 사용하지 않았다는 점에 유의하십시오. 이전 ArcView는 ArcGIS가 수행하는 모든 데이터베이스 작업을 수행 할 수있었습니다 (실제로 많은 작업에서 더 빠름).

— whuber

2

ESRI 및 기타 GIS 소프트웨어에서 피쳐 클래스 또는 데이터 세트를 작성하는 폴더 또는 파일 세트를 갖는 것이 일반적입니다.
예를 들어 arcinfo 적용 범위, shapefile, 파일 지오 데이터베이스.
이러한 "파일 세트"는 많은 GIS 기능을 허용하기 위해 소프트웨어에 의해 "결합"되어야합니다.
Attrubute 테이블, 네트워크, 토폴로지 컨트롤.
이것이 OID의 목적이며 Null을 허용하지 않고 숨겨진 소프트웨어로 제어하는 이유이기도합니다.

— 브래드 네섬
소스

저는 GIS 운영이 이와 관련이 있다고 생각합니다. 교차, (공간적) 노조, 차이 등. 누구든지 이것을 더 자세히 확인하거나 제시 할 수 있습니까?

— George Silva

단일 SDE 기능 클래스가 실제로 Oracle과 같은 데이터베이스에 어떻게 저장되는지 살펴보십시오. 속성에 대한 하나의 테이블, 형상에 대한 하나의 테이블, 공간 인덱스에 대한 하나의 테이블, 속성 인덱스에 대한 하나 이상의 테이블 등이 있습니다. ESRI가 문자열 PKEY에 대한 모든 코드 페이지 / 문자 인코딩을 지원해야하는 경우 모두 여전히 ArcView 3.x에 있습니다.

— blah238

@George-blah238에서 언급 한 것처럼 하나의 파일을 사용하여 데이터를 모두 저장하는 GIS 응용 프로그램은 거의 없습니다. 패키지에 따라 좌표, 측정 값, 속성, 규칙, 관계 등으로 구성 될 수 있습니다. 어떤 공간 행이 어떤 속성 행, 어떤 네트워크 행 등으로 진행되는지 추적하는 것이 더 중요합니다.

— Brad Nesom

1

죄송합니다. blah238,이 문제에서 코드의 양이 결정적이라고 생각하지 않습니다. enconding은 이것과 아무 관련이 없습니다. 데이터베이스는 "math"를 수행하고 일련의 문자가 같은지 여부를 결정하므로 PKEY를 시행합니다. 소프트웨어 계층에 없습니다. @ 브래드 네섬 : 그것은 또한 의미가 있습니다. 그러나 Oracle 및 PostGIS에서는 모든 속성을 단일 테이블에 저장할 수 있습니다. 쉐이프 파일에 두려운 ObjectID가 필요하다는 데 동의하고 표준을 설정했을 수 있습니까?

— George Silva

@George Shapefile은 필요하지 않으며 일반적으로 ObjectID를 사용하지 않았습니다. 그 OID 필드는 ArcGIS 8과 함께 소개되었으므로 shapefile이 질문과 관련이 있는지 의심됩니다.

— whuber