첫 번째 접근 방식인 '인접 리스트(adjacency list)'는 "분명히 유일한 방법"이라고 여겨지는 방식임.
두 번째 방식은 "훨씬 간단한 방법"으로, 이전에 본 적 없는 방식이며 명백한 결점이 있지만, 어떤 경우에는 충분히 명확함.
세 번째 방식인 '네임스페이싱(namespacing)'은 '구체화된 경로(materialized path)'라고 불림.
트리를 표현하는 또 다른 방식으로 '중첩 집합(nested sets)'이 있으며, 이는 관계형 데이터베이스를 심각하게 다루던 시절에 잘 알려진 방식임.
Postgres는 'ltree'라는 데이터 타입과 검색 연산자를 제공하여, 트리 구조를 자연스럽게 다룰 수 있음. 예를 들어, 'ltree'를 사용하여 테이블을 생성하고 데이터를 삽입한 후 간단한 검색을 통해 트리 구조를 조회할 수 있음.
구조 내의 값은 종종 표시된 트리가 아닌 데이터의 계층 구조임. 데이터를 순회하거나 관계를 보여주거나 재정렬하는 등의 작업을 수행하고 싶을 것임. 데이터베이스 내의 데이터 구조에 시각적 정보를 저장하는 것은 단기적인 시각으로 보일 수 있음.
트리 형태의 데이터를 다루는 회사를 창업한 경험이 있음. 트리 구조를 O(n) 시간에 들여서 들여쓰기된 목록으로 변환하는 것이 가능함. 이는 인터뷰 질문 중 하나였으며, 재귀적 쿼리 없이도 트리의 일부를 빠르게 가져오고 렌더링할 수 있는 다양한 방법이 SQL 데이터베이스에 존재함.
SQL 쿼리를 사용하여 관계형 데이터베이스에서 트리 구조 데이터를 가져오는 한 가지 방법은 재귀적인 CTE(Common Table Expressions)를 작성하는 것임. CTE는 실제로 재미있으며, 한 번 익숙해지면 두려워할 것이 없음.
사람들은 종종 실제로 트리를 원하지 않으며, 단지 트리의 외관만 필요로 함을 경험을 통해 배움. HN과 Reddit은 이 점에서 차이가 있음. HN에서는 자식 댓글이 부모 댓글의 다음 형제로, 들여쓰기를 부모의 들여쓰기에 하나를 더해 트리의 외관을 모방함. 반면 Reddit에서는 자식 댓글이 실제로 부모 댓글 내에 중첩됨.
기사의 핵심 아이디어는 문제에 적합한 구조를 사용하는 것임. 그러나 이야기의 전개는 결함이 있음. 트리를 데이터베이스에서 검색하기 위해 CTE가 필요하지 않으며, 트리를 로컬에서 구성하기 위해 평면 목록을 가져올 수 있음. 또한, 충분히 큰 트리의 경우 가지를 이동하거나 깊이를 변경하고자 할 때 선형 비용이 발생할 수 있음.
분류 체계나 다른 계층 구조를 설명할 때, 로컬 파일 시스템을 사용하는 간단하고 빠른 방법을 습득함. 'mkdir'와 'tree' 명령을 사용하여 이메일, 슬랙, pastebin 등에 붙여넣어 전달함.
저장/로딩만 원한다면, 데이터를 원하는 방식으로 직렬화(예: JSON)하여 문자열로 저장하는 것이 더 단순한 해결책일 수 있음. 점 표기법을 사용하는 것은 VsCode 확장 프로그램인 Dendron이 이름 계층을 다루는 방식과 유사함.
몇 년 전 OpenGL에 대한 비슷한 깨달음을 얻음: 계층적인 3D 객체의 세계를 그릴 필요가 없으며, 단지 정렬된 삼각형 목록을 그리면 됨. 이는 많은 최적화를 매우 쉽게 만듦.
Hacker News 의견
첫 번째 접근 방식인 '인접 리스트(adjacency list)'는 "분명히 유일한 방법"이라고 여겨지는 방식임.
두 번째 방식은 "훨씬 간단한 방법"으로, 이전에 본 적 없는 방식이며 명백한 결점이 있지만, 어떤 경우에는 충분히 명확함.
세 번째 방식인 '네임스페이싱(namespacing)'은 '구체화된 경로(materialized path)'라고 불림.
트리를 표현하는 또 다른 방식으로 '중첩 집합(nested sets)'이 있으며, 이는 관계형 데이터베이스를 심각하게 다루던 시절에 잘 알려진 방식임.
Postgres는 'ltree'라는 데이터 타입과 검색 연산자를 제공하여, 트리 구조를 자연스럽게 다룰 수 있음. 예를 들어, 'ltree'를 사용하여 테이블을 생성하고 데이터를 삽입한 후 간단한 검색을 통해 트리 구조를 조회할 수 있음.
구조 내의 값은 종종 표시된 트리가 아닌 데이터의 계층 구조임. 데이터를 순회하거나 관계를 보여주거나 재정렬하는 등의 작업을 수행하고 싶을 것임. 데이터베이스 내의 데이터 구조에 시각적 정보를 저장하는 것은 단기적인 시각으로 보일 수 있음.
트리 형태의 데이터를 다루는 회사를 창업한 경험이 있음. 트리 구조를 O(n) 시간에 들여서 들여쓰기된 목록으로 변환하는 것이 가능함. 이는 인터뷰 질문 중 하나였으며, 재귀적 쿼리 없이도 트리의 일부를 빠르게 가져오고 렌더링할 수 있는 다양한 방법이 SQL 데이터베이스에 존재함.
SQL 쿼리를 사용하여 관계형 데이터베이스에서 트리 구조 데이터를 가져오는 한 가지 방법은 재귀적인 CTE(Common Table Expressions)를 작성하는 것임. CTE는 실제로 재미있으며, 한 번 익숙해지면 두려워할 것이 없음.
사람들은 종종 실제로 트리를 원하지 않으며, 단지 트리의 외관만 필요로 함을 경험을 통해 배움. HN과 Reddit은 이 점에서 차이가 있음. HN에서는 자식 댓글이 부모 댓글의 다음 형제로, 들여쓰기를 부모의 들여쓰기에 하나를 더해 트리의 외관을 모방함. 반면 Reddit에서는 자식 댓글이 실제로 부모 댓글 내에 중첩됨.
기사의 핵심 아이디어는 문제에 적합한 구조를 사용하는 것임. 그러나 이야기의 전개는 결함이 있음. 트리를 데이터베이스에서 검색하기 위해 CTE가 필요하지 않으며, 트리를 로컬에서 구성하기 위해 평면 목록을 가져올 수 있음. 또한, 충분히 큰 트리의 경우 가지를 이동하거나 깊이를 변경하고자 할 때 선형 비용이 발생할 수 있음.
분류 체계나 다른 계층 구조를 설명할 때, 로컬 파일 시스템을 사용하는 간단하고 빠른 방법을 습득함. 'mkdir'와 'tree' 명령을 사용하여 이메일, 슬랙, pastebin 등에 붙여넣어 전달함.
저장/로딩만 원한다면, 데이터를 원하는 방식으로 직렬화(예: JSON)하여 문자열로 저장하는 것이 더 단순한 해결책일 수 있음. 점 표기법을 사용하는 것은 VsCode 확장 프로그램인 Dendron이 이름 계층을 다루는 방식과 유사함.
몇 년 전 OpenGL에 대한 비슷한 깨달음을 얻음: 계층적인 3D 객체의 세계를 그릴 필요가 없으며, 단지 정렬된 삼각형 목록을 그리면 됨. 이는 많은 최적화를 매우 쉽게 만듦.