Làm thế nào tôi nên thiết kế một bảng mối quan hệ cho tình bạn?

Nếu Alà một người bạn của tôi B, thì tôi nên lưu trữ cả hai giá trị ABvà BA, hoặc một giá trị là đủ? Những lợi thế và bất lợi của cả hai phương pháp là gì.

Đây là quan sát của tôi:

• Nếu tôi giữ cả hai thì tôi phải cập nhật cả hai khi nhận được yêu cầu từ một người bạn.
• Nếu tôi không giữ cả hai, thì tôi thấy khó khăn khi phải thực hiện nhiều lần JOINvới bảng này.

Hiện tại, tôi giữ mối quan hệ một chiều.

Vậy tôi nên làm gì trong trường hợp này? Có lời khuyên nào không?

Tôi sẽ lưu trữ AB và BA. Một tình bạn thực sự là một mối quan hệ hai chiều, mỗi thực thể được liên kết với nhau. Mặc dù theo trực giác, chúng tôi nghĩ rằng "tình bạn" là một liên kết giữa hai người, từ quan điểm quan hệ, nó giống như "A có một người bạn B" và "B có một người bạn A". Hai mối quan hệ, hai hồ sơ.

Nếu tình bạn được dự định là đối xứng (nghĩa là không thể A kết bạn Bnhưng không phải ngược lại) thì tôi sẽ chỉ lưu trữ mối quan hệ một chiều với một ràng buộc kiểm tra để đảm bảo rằng mỗi mối quan hệ chỉ có thể được biểu diễn theo một cách.

Ngoài ra, tôi sẽ bỏ id thay thế và có PK tổng hợp thay thế (và có thể là một chỉ số duy nhất tổng hợp cũng trên các cột đảo ngược).

CREATE TABLE Friends
  (
     UserID1 INT NOT NULL REFERENCES Users(UserID),
     UserID2 INT NOT NULL REFERENCES Users(UserID),
     CONSTRAINT CheckOneWay CHECK (UserID1 < UserID2),
     CONSTRAINT PK_Friends_UserID1_UserID2 PRIMARY KEY (UserID1, UserID2),
     CONSTRAINT UQ_Friends_UserID2_UserID1 UNIQUE (UserID2, UserID1)
  ) 

Bạn không nói các truy vấn gây khó khăn nhưng bạn luôn có thể tạo Chế độ xem

CREATE VIEW Foo
AS
SELECT UserID1,UserID2 
FROM Friends
UNION ALL
SELECT UserID2,UserID1 
FROM Friends

Giả sử một "tình bạn" luôn là hai chiều / lẫn nhau, có lẽ tôi sẽ xử lý nó như thế này.

CREATE TABLE person (
    person_id int IDENTITY(1,1) PRIMARY KEY,
    ...other columns...
)

CREATE TABLE friendship (
    friendship_id int IDENTITY(1,1) PRIMARY KEY,
    ...other columns, if any...
)

CREATE TABLE person_friendship (
    person_id int NOT NULL,
    friendship_id int NOT NULL
    PRIMARY KEY (person_id, friendship_id)
)

Kết quả là bạn thay đổi nó từ một người tham gia nhiều người từ "người" thành "người", thành người tham gia nhiều người từ "người" sang "tình bạn". Điều này sẽ đơn giản hóa việc tham gia và các ràng buộc, nhưng có tác dụng phụ là cho phép nhiều hơn hai người trong một "tình bạn" (mặc dù có thể sự linh hoạt bổ sung sẽ là một lợi thế tiềm năng).

Bạn có thể cần xác định các chỉ mục xung quanh mối quan hệ bạn bè thay vì nhân đôi số lượng hàng:

CREATE TABLE person
(
    person_id INT NOT NULL AUTO_INCREMENT,
    ...
    PRIMARY KEY (person_id)
);
CREATE TABLE friendship
(
    friend_of INT NOT NULL,
    friend_to INT NOT NULL,
    PRIMARY KEY (friend_of,friend_to),
    UNIQUE KEY friend_to (friend_to,friend_of)
);

Bằng cách này, bạn tăng gấp đôi dung lượng lưu trữ cho các chỉ mục nhưng không phải cho dữ liệu bảng. Do đó, đây sẽ là một khoản tiết kiệm 25% trên không gian đĩa. Trình tối ưu hóa truy vấn MySQL sẽ chọn chỉ thực hiện quét phạm vi chỉ mục, đó là lý do tại sao khái niệm bao phủ các chỉ mục hoạt động tốt ở đây.

Dưới đây là một số liên kết đẹp về Chỉ số che phủ:

• http://peter-zaitsev.livejournal.com/6949.html
• http://www.mysqlperformanceblog.com/2006/11/23/covering-index-and-prefix-indexes/
• http://ronaldbradford.com/blog/tag/covering-index/

CẨN THẬN

Nếu tình bạn không có nhau, bạn có cơ sở cho một loại mối quan hệ khác: SAU

Nếu friend_to không phải là bạn của friend_of, bạn có thể bỏ mối quan hệ đó ra khỏi bàn.

Nếu bạn muốn xác định mối quan hệ cho tất cả các loại, cho dù chúng có tương hỗ hay không, bạn có thể sử dụng cách bố trí bảng sau:

CREATE TABLE person
(
    person_id INT NOT NULL AUTO_INCREMENT,
    ...
    PRIMARY KEY (person_id)
);
CREATE TABLE relationship
(
    rel_id INT NOT NULL AUTO_INCREMENT,
    person_id1 INT NOT NULL,
    person_id2 INT NOT NULL,
    reltype_id TINYINT,
    PRIMARY KEY (rel_id),
    UNIQUE KEY outer_affinity (reltype_id,person_id1,person_id2),
    UNIQUE KEY inner_affinity (reltype_id,person_id2,person_id1),
    KEY has_relationship_to (person1_id,reltype_id),
    KEY has_relationship_by (person2_id,reltype_id)
);
CREATE TABLE relation
(
    reltype_id TINYINT NOT NULL AUTO_INCREMENT,
    rel_name VARCHAR(20),
    PRIMARY KEY (reltype_id),
    UNIQUE KEY (rel_name)
);
INSERT INTO relation (relation_name) VALUES
('friend'),('follower'),('foe'),
('forgotabout'),('forsaken'),('fixed');

Từ bảng quan hệ, bạn có thể sắp xếp các mối quan hệ để bao gồm:

• Bạn bè nên tương thân
• Kẻ thù có thể là tương hỗ hoặc không
• Người theo dõi có thể tương hỗ hoặc không
• Các mối quan hệ khác sẽ chịu sự giải thích (bởi sự lãng quên hoặc bị bỏ rơi hoặc người nhận trả thù (đã sửa))
• Mối quan hệ có thể được mở rộng hơn nữa

Điều này nên mạnh mẽ hơn cho tất cả các mối quan hệ, cho dù mối quan hệ là tương hỗ hay không.

Nếu bạn có thể kiểm soát trong ứng dụng, id của A luôn thấp hơn id của B (đặt trước các id phần tử A, B), bạn có thể tận dụng yêu cầu mà không cần OR (chọn nơi id_A = a AND id_B = b, thay vì hỏi (id_A = a AND id_B = b) HOẶC (id_A = b AND id_B = a)) và cũng duy trì một nửa số hồ sơ bạn sẽ cần với các xấp xỉ của người khác. Sau đó, bạn nên sử dụng một lĩnh vực khác để duy trì trạng thái của mối quan hệ (là bạn bè, a-solicited-to-b, b-solicited-to-a, exfriends-a, exfriends-b), và bạn đã hoàn thành.

Đây là cách tôi đã quản lý hệ thống tình bạn của mình và điều này giúp đơn giản hóa hệ thống và sử dụng một nửa số hàng bạn sẽ cần với các hệ thống khác, chỉ nói A bằng với giá trị id thấp hơn trong mã.