하나의 PostGIS 테이블에서 지오메트리 유형 혼합

나는 다음과 같은 문제에 직면 해있다. Oracle 데이터베이스에서 PostgreSQL + PostGIS로 마이그레이션해야합니다. 현재 모든 유형의 모든 형상이 하나의 테이블에 저장되며 각 레코드에는 동일한 계층의 기능을 나타내는 "lid"필드가 포함됩니다.

그러한 방법을 사용할 때의 장단점은 무엇입니까? 타사 소프트웨어와 함께 데이터베이스를 사용할 필요가없는 경우 데이터를 여러 테이블로 분할해야합니까? 공간 쿼리의 성능은 어떻습니까? 인덱스가 도움이됩니까?

타사 지원이 필요하지 않고 동일한 테이블에 유지하여 유형별로 쿼리 할 필요가 없다면 잘 작동합니다. 또는 PostGIS 작동의 3 장에서 설명한대로 상속 모델을 사용할 수 있습니다.

http://www.postgis.us/chapter_03_edition_1

아키텍처 관점에서 PostGIS는 쿼리에서 여러 유형이 사용되는지 실제로 신경 쓰지 않습니다. Oracle에서 성능이 좋으면 PostGIS에서 성능이 좋지 않은 것처럼 보입니다.

분할해야하는 두 가지 이유가 있습니다 (필요에 따라 나중에 수행 할 수도 있음). 1) 지오메트리 컬렉션, 원형 문자열 및 원하지 않는 유형 (원하는 제약 조건을 직접 정의 할 수있는 유형)과 같이 원하지 않는 다른 유형을 사람들이 삽입하지 못하도록 방지 )

2) 10 억 개의 점과 1000 개의 다각형이 있고 다각형 테스트에서 많은 점을 수행하는 경우, 10 억 개에서 1000 개까지의 레코드 테이블을 쿼리하고 조인 할 때 속도가 훨씬 향상됩니다. 10 억에서 10 억의 레코드 테이블. 이것은 내가 생각하는 모든 공간 데이터베이스 (PostGIS에 국한되지 않음)의 경우입니다. 내가 생각할 모든 관계형 쿼리에 대해서도 마찬가지입니다 (공간 쿼리에만 국한되지 않음).

이것은 정말로 나를 괴롭힌다. 하나의 레이어에 데이터가있는 CAD 파일이 너무 많아 색상으로 만 구분 되었기 때문인 것 같습니다.

그 결과는 구조 또는 속성별로 데이터 를 구성하는 것 중에서 실제로 선택 하는 것 입니다.

그 선택을 감안할 때, 나는 항상 데이터 구조를 통해 데이터를 정리하려고합니다.

시작을 위해 데이터를 처리 할 때 건너 뛸 하나의 고리가 적습니다 (예 : id = X AND lid = Y 인 테이블에서 a, b, c 를 선택하는 대신 id = X 인 테이블에서 a, b, c 를 선택하십시오 )

그런 다음 데이터베이스가 여러 테이블을 허용하는 이유를 고려하십시오. 데이터 형식이 특정 데이터 구조를 제공하는 경우 데이터를 사용하면 데이터를보다 효율적으로 처리 할 것이라고 생각해야합니다.

그러나 가장 큰 문제는 데이터를 다른 시스템으로 옮길 때입니다. 그런 다음 최종 응용 프로그램이 동일한 방식으로 데이터를 사용하지 않을 수 있기 때문에 이것이 실제 과제가된다고 생각합니다. 이 시나리오에서 많은 사람들이 방해를받지 않는 것을 보았습니다.

따라서 제 경험상 데이터가 적절한 (깊고 구조화 된) 데이터 모델을 가지고있을 때 데이터를 두 배 더 효율적으로 사용하고 전송할 수 있습니다.