답변:
HierarchyID를 구현했으며 좋은 성능과 사용하기 쉬운 것으로 나타났습니다.
나는 최대 10 가지의 계층 구조를 가진 비교적 작은 데이터 세트 (수만 행)에 사용했습니다.
왜 사용합니까? HierarchyID 유형은 IsDescendantOf자체 구체화 된 경로를 롤링하는 것보다 작업을보다 쉽게 해주는 여러 가지 도우미 메서드 (예 :)를 제공합니다 .
StackOverflow에 대한 Paul Nielsen의 의견은 혼란 스럽습니다. HierarchyID 는 구체화 된 경로입니다. 그의 답변 아래 에이 의견 에 동의하는 경향 이 있습니다.
더 좋은 질문은 '사용하지 않는 이유'입니다. 사용하기 쉽고, 직접 작성해야 할 많은 기능을 제공하며, 제한된 테스트에서 잘 수행됩니다.
이것은 Kirk의 '사용하지 않는 이유 (HierarchyId)'에 대한 답변입니다. 구체화 된 경로와 비교할 때 일부 중요한 경우 HierarchyId는 성능이 떨어지고 작업하기 편리하지 않은 것으로 보입니다.
그 이유는 간단합니다. Connect에 대한 Microsoft 의견의 인용 에 따르면, "문제는 hierarchyID의 메소드를 포함한 CLR 호출이 쿼리 최적화 프로그램에 불투명하기 때문입니다. 이것은 의도적으로 설계된 것입니다. 그러나 때때로 카디널리티 추정치가 상당히 클 수 있습니다. 잘못된."
다른 한편으로, 구체화 된 경로를 구현하는 것은 우리가 처음으로해야 할 때 매우 쉽고, 다음에는 본질적으로 복사하여 붙여 넣기 작업입니다. 따라서 적은 노력으로보다 다양하고 우수한 성능의 솔루션을 얻을 수 있습니다.
그래서 저는 "Microsoft® SQL Server® 2008 Bible"이라는 제목의 훌륭한 저서에 다음과 같이 썼던 Paul Nielsen에 전적으로 동의합니다. "새로운 HierarchyID는 논쟁의 여지가 없습니다. 다른 솔루션이 필요한 문제인지 확실하지 않습니다. "
우리 회사는 직접 판매, 다단계 마케팅 소프트웨어에서 HeirachyID를 사용합니다. 작동합니다. 나는 실제로 어떤 작업을 수행하지 않았으며 우리가 사용하고 있음을 알고 있습니다.
내가 본 가장 큰 문제는 더 많은 설정 기반이 아닌 반복 방식으로 레벨을 반복한다는 것입니다. 이 영역에서는 실제로 성능이 좋지 않지만 유형이나 구현에 문제가 있는지 확실하지 않습니다.
hierarchyid의 한 가지 문제는 공급 업체를 잠그는 것입니다. 그러나 Adam Milazzo가 모든 것이 내부적으로 작동하는 방식에 대한 훌륭한 기사를 찾았습니다.
http://www.adammil.net/blog/view.php?id=100
이를 통해 MSSQL에서 내 데이터 세트를 변환하는 Postgres 스크립트를 작성할 수있었습니다. 또한 AdventureWorks 데이터베이스를 Postgres로 가져 오기 위해 작성한 스크립트에 포함했습니다.
https://github.com/lorint/AdventureWorks-for-Postgres
install.sql 파일에서 "hierarchyid"를 검색하면 곧 변환에 대한 참조를 찾을 수 있습니다.