Mô-đun Ltree của PostgreSQL có phù hợp với các nhận xét được tạo luồng không?

Question

Tôi đang cân nhắc việc sử dụng Ltree module của PostgreSQL trong đơn đăng ký của tôi để trợ giúp với các nhận xét theo chuỗi. Tôi đã nhìn nó một lúc để sử dụng cho các bình luận luồng. Tôi nghĩ nó sẽ giúp ích cho các trường hợp bạn cần cập nhật một nút và các nút con của nó, như khi bạn muốn ẩn một bình luận và các câu trả lời của nó.

Tôi đang nghĩ ltree (hoặc một cái gì đó giống như nó) nó sẽ hữu ích nếu nó được kết hợp với một danh sách kề kề truyền thống ("comment_id"/"parent_comment_id").

Trước khi lao vào sử dụng ltree, tôi đang tự hỏi một vài điều:

1. Bạn có, hay bạn, sử dụng ltree? Có phải đó là điều mà người ta có thể gọi là "sản xuất đã sẵn sàng" không?
2. Nếu có, bạn đã sử dụng vấn đề gì để giải quyết? Nó có làm tốt không?
3. Bạn có cho rằng nó phù hợp với hệ thống nhận xét luồng không?
   4. Nếu bạn đã sử dụng nó, bạn đã sử dụng gì cho phần "văn bản" của đường dẫn? Bạn đã thiết lập một cái gì đó giống như ví dụ DMOZ họ sử dụng "Top.Astronomy.Cosmology" hoặc dựa trên một cái gì đó giống như khóa chính "1.403.29.5"?
   5. Có cách nào tốt hơn để thực hiện việc này không? Tôi hơi lo lắng khi sử dụng một cách tiếp cận danh sách lồng nhau - tất cả những gì tôi đã đọc cho thấy rằng nó không phải là tất cả để nóng với CẬP NHẬT hoặc INSERTS (không bạn phải sắp xếp lại toàn bộ điều?). Tôi cũng không phải là một CS lớn và cấu trúc dữ liệu đó là thứ mà tôi có thể quên trong tương lai. Có ai đang sử dụng danh sách lồng nhau cho các bình luận hoặc một cái gì đó giống như nó?

Nếu nó là của bất kỳ sự giúp đỡ, đây là lược đồ tôi đang xem xét:

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 
); 

Các "con đường" cột, được sử dụng bởi ltree, sẽ giống như thế:

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

Có điều gì sai khi sử dụng các khóa chính trong đường dẫn không? Tôi có nên bao gồm khóa chính của nút trong đường dẫn không? Nếu tôi đã làm, nó sẽ có ý nghĩa để đặt một chỉ số duy nhất trên nó để phục vụ như là một hạn chế?

Answer 1

1. Có và vâng;
2. Phân cấp các phần trong cơ sở kiến ​​thức (một trong các triển khai);
3. Có;

Định nghĩa của một trong các bảng trong câu hỏi:

            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') 

Các "con đường" cột sử dụng khóa chính là một nhãn.

Một ví dụ về các nội dung hiện tại của bảng đó (liên quan đến khóa chính và cột "con đường"):

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

Answer 2

Phiên bản 8.4 của PostgreSQL sẽ mang chức năng Biểu thức bảng chung vào lõi với các biểu thức WITH và WITH... RECURSIVE. Nếu bạn đang sửa đổi mã cũ, bạn có thể đợi đến khi 8.4 được phát hành, khi đó bạn sẽ không phải lo lắng về bất kỳ sự không tương thích nào giữa Ltree và cú pháp lõi mới. Nếu bạn đang làm việc với mã cũ, hoặc không muốn đợi 8.4, có thể bạn sẽ muốn chắc chắn rằng bạn viết mã dễ dàng dịch sang cú pháp mới, đặc biệt nếu bạn thay đổi một lược đồ cũ hoặc thiết kế một một.

Xem thêm:

• The 8.4 manual entry on WITH queries and CTEs
• A writeup with examples on the 8.4 implementation of CTEs

Answer 3

Tôi khuyên bạn nên bất cứ ai thực hiện mối quan hệ thứ bậc trong SQL đọc Joe Celko's Trees and Hierarchies in SQL for Smarties.

Di chuyển các liên kết con phụ huynh có chiều sâu tùy ý có thể rất không hiệu quả khi chỉ sử dụng parent_id. Cuốn sách mô tả các kỹ thuật giúp truy cập nhanh này.

Một chiến lược (mà tôi xảy ra để sử dụng) cũng có thể được tìm thấy miễn phí trong loạt bài này:

• Part 1 (tìm kiếm phần "Cây trong SQL") (Wayback link)
• Part 2 (Wayback link)
• Part 3 (Wayback link)
• Part 4 (Wayback link)