Cấu trúc cơ sở dữ liệu cho cấu trúc dữ liệu cây


151

Điều gì sẽ là cách tốt nhất để thực hiện cấu trúc dữ liệu cây có thể tùy chỉnh (nghĩa là cấu trúc cây với số lượng mức độ không xác định) trong cơ sở dữ liệu?

Tôi đã làm điều này một lần trước khi sử dụng một bảng có khóa ngoại.

Những triển khai nào khác mà bạn có thể thấy, và việc triển khai này có ý nghĩa gì không?



SQL Server (từ năm 2008) cung cấp kiểu dữ liệu phân cấp
BornToCode

Câu trả lời:


80

Bạn đề cập đến việc được triển khai phổ biến nhất, đó là Danh sách điều chỉnh: https://bloss.msdn.microsoft.com/mvpawardprogram/2012/06/25/hierarchies-convert-adjacency-list-to-nested-sets

Ngoài ra còn có các mô hình khác, bao gồm đường dẫn được vật chất hóa và các tập hợp lồng nhau: http://cransities.bmc.com/cransities/docs/DOC-9902

Joe Celko đã viết một cuốn sách về chủ đề này, đây là một tài liệu tham khảo tốt từ quan điểm SQL chung (nó được đề cập trong liên kết bài viết tập hợp lồng nhau ở trên).

Ngoài ra, Itzik Ben-Gann có một cái nhìn tổng quan về các tùy chọn phổ biến nhất trong cuốn sách "Inside Microsoft SQL Server 2005: Truy vấn T-SQL".

Những điều chính cần xem xét khi chọn một mô hình là:

1) Tần suất thay đổi cấu trúc - tần suất thay đổi cấu trúc thực tế của cây. Một số mô hình cung cấp các đặc điểm cập nhật cấu trúc tốt hơn. Tuy nhiên, điều quan trọng là phải tách các thay đổi cấu trúc khỏi các thay đổi dữ liệu khác. Ví dụ: bạn có thể muốn lập mô hình sơ đồ tổ chức của công ty. Một số người sẽ mô hình hóa nó như một danh sách kề, sử dụng ID nhân viên để liên kết một nhân viên với người giám sát của họ. Đây thường là một cách tiếp cận phụ tối ưu. Một cách tiếp cận thường hoạt động tốt hơn là mô hình hóa cấu trúc org tách biệt với chính nhân viên và duy trì nhân viên như một thuộc tính của cấu trúc. Theo cách này, khi một nhân viên rời khỏi công ty, bản thân cấu trúc tổ chức không cần phải thay đổi, chỉ cần sự liên kết với nhân viên còn lại.

2) Cây viết nặng hay đọc nặng - một số cấu trúc hoạt động rất tốt khi đọc cấu trúc, nhưng phải chịu thêm chi phí khi ghi vào cấu trúc.

3) Những loại thông tin nào bạn cần có được từ cấu trúc - một số cấu trúc nổi trội trong việc cung cấp các loại thông tin nhất định về cấu trúc. Các ví dụ bao gồm tìm một nút và tất cả các con của nó, tìm một nút và tất cả các cha mẹ của nó, tìm số nút con đáp ứng các điều kiện nhất định, v.v. Bạn cần biết thông tin nào sẽ cần từ cấu trúc để xác định cấu trúc phù hợp nhất bạn cần.


Xin chào, tôi đang đối mặt với chính xác vấn đề tương tự được nêu trong câu hỏi này và muốn hỏi bạn một câu hỏi về các chủ đề trên. Xem xét một cấu trúc như trong chủ đề số một (bảng cấu trúc tổ chức (không phải cấu trúc nhân viên) với ParentId được tham chiếu trong cùng một bảng), tôi cần đặt ai là ông chủ của một khu vực nhất định. Tôi sẽ chỉ định tất cả các nhân viên của khu vực cụ thể đó trực tiếp đến nó. Bạn sẽ đặt ông chủ của khu vực cụ thể đó ở đâu? Bên trong cùng một khu vực hoặc một gorup ở trên? Cách tiếp cận của tôi là giới thiệu anh ấy / cô ấy đến nhóm ở trên, điều đó mang lại cho tôi một cấu trúc tốt hơn tôi nghĩ. Cảm ơn.
Marcos Buarque

1
Liên kết đầu tiên dường như bị phá vỡ.
Jorge Leitao

Câu trả lời tuyệt vời. Cảm ơn @JeremyDWill!
bobocopy

56

Hãy xem Quản lý dữ liệu phân cấp trong MySQL . Nó thảo luận về hai cách tiếp cận để lưu trữ và quản lý dữ liệu phân cấp (giống như cây) trong cơ sở dữ liệu quan hệ.

Cách tiếp cận đầu tiên là mô hình danh sách kề, đó là những gì bạn mô tả về cơ bản: có một khóa ngoại liên quan đến chính bảng. Mặc dù cách tiếp cận này đơn giản, nhưng nó có thể rất kém hiệu quả đối với một số truy vấn nhất định, như xây dựng toàn bộ cây.

Cách tiếp cận thứ hai được thảo luận trong bài viết là mô hình tập hợp lồng nhau. Cách tiếp cận này hiệu quả và linh hoạt hơn nhiều. Tham khảo bài viết để giải thích chi tiết và truy vấn ví dụ.


liên kết của bạn có một chủ đề rất thú vị đang được thảo luận. cảm ơn!
Fritz

9

Nếu bạn phải sử dụng Relative DataBase để tổ chức cấu trúc dữ liệu cây thì Postgresql có mô đun ltree tuyệt vời cung cấp kiểu dữ liệu để biểu diễn các nhãn dữ liệu được lưu trữ trong cấu trúc giống như cây phân cấp. Bạn có thể lấy ý tưởng từ đó. (Để biết thêm thông tin, hãy xem: http://www.postgresql.org/docs/9.0/static/ltree.html )

Trong LDAP chung được sử dụng để tổ chức các bản ghi trong cấu trúc phân cấp.


2

Có một bảng với một khóa ngoại cho chính nó có ý nghĩa với tôi.

Sau đó, bạn có thể sử dụng một biểu thức bảng chung trong SQL hoặc kết nối bằng câu lệnh trước trong Oracle để xây dựng cây của bạn.


Tôi có một bảng nhật ký, với cột nhận dạng LogID và cột ParentLogID có FK trỏ về cột LogID. Khi hàng nhật ký đầu tiên trong một giao dịch được viết, tôi lấy SCOPE_IDENTITY (). Tất cả các bản ghi nhật ký khác được ghi với giá trị này trong cột ParentLogID. Điều này thực sự hữu ích cho việc nhóm các hàng thuộc về nhau. Đó là cách thực sự duy nhất để xem những gì đã xảy ra, nếu không có điều này, nó sẽ là một mớ hỗn độn lớn của các hàng nhật ký từ nhiều giao dịch được trộn lẫn với nhau.
KM.

@KM - Anh ấy nói "không có ý nghĩa" chứ không phải "không có ý nghĩa"
John Rasch



Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.