PostgreSQL의 LTREE 모듈은 스레드 주석에 적합합니까?

https://stackoverflow.com/questions/603894

03-07-2019
|

문제

PostgreSQL을 사용하는 것을 고려하고 있습니다 ltree 모듈 내 응용 프로그램에서 스레드 댓글을 돕습니다. 나는 스레드 댓글에 사용하기 위해 잠시 동안 그것을 눈에 띄었습니다. 나는 당신이 코멘트와 그 답을 숨기고 싶을 때와 같이 노드와 그 어린이를 업데이트 해야하는 경우에 도움이 될 것이라고 생각합니다.

Ltree (또는 이와 비슷한 것)가 전통적인 인접 목록 ( "Comment_id"/"Parent_comment_id")과 결합 된 경우 유용 할 것이라고 생각합니다.

Ltree를 사용하는 데 뛰어 들기 전에 몇 가지 궁금합니다.

당신은 또는 당신이 Ltree를 사용 했습니까? "생산 준비"라고 부르는 것입니까?
그렇다면 어떤 문제를 해결하는 데 사용 했습니까? 좋은 일을 했습니까?
스레드 코멘트 시스템에 적합하다고 생각하십니까?
1. 당신이 그것을 사용했다면, 당신은 경로의 "텍스트"부분에 무엇을 사용 했습니까? "top.astronomy.cosmology"를 사용하는 dmoz 예제와 같은 것을 설정 했습니까?
2. 더 좋은 방법이 있습니까? 나는 중첩 된 목록 접근법을 사용하여 약간 긴장합니다. 내가 읽은 모든 것은 그것이 모두 업데이트 나 삽입물로 뜨겁지 않다는 것을 암시합니다 (모든 것을 재정렬 할 필요는 없습니까?). 나는 또한 CS 전공이 아니며 그런 종류의 데이터 구조는 앞으로 잊어 버릴 수있는 것입니다. 댓글이나 그와 같은 중첩 목록을 사용하는 사람이 있습니까?

도움이된다면 여기에 고려해야 할 스키마가 있습니다.

CREATE TABLE comments (
    comment_id SERIAL PRIMARY KEY,
    parent_comment_id int REFERENCES comments(comment_id) ON UPDATE CASCADE ON DELETE CASCADE,
    thread_id int NOT NULL  REFERENCES threads(thread_id) ON UPDATE CASCADE ON DELETE CASCADE,
    path ltree NOT NULL,
    comment_body text NOT NULL,
    hide boolean not null default false
);

Ltree가 사용하는 "Path"열은 다음과 같습니다.

<thread_id>.<parent_comment_id_#1>.<parent_comment_id_#2>.<my_comment_id>

경로에서 기본 키를 사용하는 데 문제가 있습니까? 경로에 노드 자체의 기본 키를 포함시켜야합니까? 내가 그렇게했다면, 제약으로 사용하기 위해 고유 한 색인을 넣는 것이 합리적입니까?

해결책

예 그리고 네;
지식 기반에서 섹션의 계층 구조 (구현 중 하나);
예;

문제의 테이블 중 하나의 정의 :

                                                   Table "knowledgebase.section"
           Column           |           Type           |                                  Modifiers
----------------------------+--------------------------+-----------------------------------------------------------------------------
 section_sid                | integer                  | not null default nextval('knowledgebase.section_section_sid_seq'::regclass)
 section                    | character varying        | not null
 description                | character varying        |
 path                       | ltree                    | not null
 is_active                  | boolean                  | not null default true
 role_sid                   | integer                  | not null
 last_modified_by           | integer                  | not null
 creation_datetime          | timestamp with time zone | not null default now()
 last_modification_datetime | timestamp with time zone | not null default now()
 is_expanded                | boolean                  | not null default false
 section_idx                | tsvector                 |
Indexes:
    "section_sid_pkey" PRIMARY KEY, btree (section_sid)
    "section_section_key" UNIQUE, btree (section)
    "idxsection_idx" gist (section_idx)
    "path_gist_idx" gist (path)
Foreign-key constraints:
    "last_modified_by_fkey" FOREIGN KEY (last_modified_by) REFERENCES "user"."role"(role_sid) ON UPDATE CASCADE ON DELETE RESTRICT
    "role_sid_fkey" FOREIGN KEY (role_sid) REFERENCES "user"."role"(role_sid) ON  UPDATE CASCADE ON DELETE RESTRICT
Triggers:
    section_idx_update BEFORE INSERT OR UPDATE ON knowledgebase.section FOR EACH ROW EXECUTE PROCEDURE tsearch2('section_idx', 'section')

"Path"열은 기본 키를 레이블로 사용합니다.

해당 테이블의 현재 내용 샘플 (기본 키 및 "경로"열에 관한) :

  section_sid | path
 -------------+-------
           53 | 34.53
           56 | 56
           55 | 29.55
           35 | 35
           54 | 34.54
           37 | 30.37
          ... | ...

다른 팁

SQL 읽기에서 계층 적 관계를 구현하는 사람은 누구나 권장합니다 Joe Celko의 나무와 Smlies for Smarties의 Trees and Hierrarchies.

임의의 깊이를 가로 지르는 부모 하위 링크는 Parent_ID 만 사용할 때 매우 비효율적 일 수 있습니다. 이 책은이 액세스를 빠르게 만드는 기술을 설명합니다.

이 일련의 기사에서 한 가지 전략 (내가 사용하는)도 무료로 찾을 수 있습니다.

PostgreSQL의 버전 8.4는 공통 테이블 표현식 기능을 코어로 가져옵니다 WITH 그리고 WITH... RECURSIVE 표현. 이전 코드를 수정하는 경우 8.4가 릴리스 될 때까지 기다릴 수 있습니다. LTREE와 새로운 Core 구문 간의 비 호환성에 대해 걱정할 필요가 없습니다. 이전 코드로 작업하거나 8.4를 기다리지 않는 경우 특히 기존 스키마를 변경하거나 새로 설계하는 경우 새 구문에 쉽게 번역 할 수있는 코드를 작성해야 할 것입니다. 하나.

또한보십시오:

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow