Як я повинен створити таблицю стосунків для дружби?

Якщо Aє другом B, то чи варто зберігати обидва значення ABта BA, або одного достатньо? Які переваги та недоліки обох методів.

Ось моє спостереження:

• Якщо я зберігаю обоє, мені доведеться поновлювати обидва, коли отримую запит від друга.
• Якщо я не дотримуюсь обох, то мені було складно, коли мені доведеться робити кілька разів JOINз цією таблицею.

В даний час я підтримую відносини в один бік.

То що мені робити в цьому випадку? Будь-яка порада?

Я б зберігав AB та BA. Дружба - це дійсно двосторонні стосунки, кожна сутність пов'язана з іншою. Хоча інтуїтивно ми думаємо про "дружбу" як про один зв'язок між двома людьми, з реляційної точки зору це більше схоже на "А має друга Б" і "В має друга А". Два стосунки, два записи.

Якщо дружба покликана бути симетричною (тобто неможливо A дружити, Bале не навпаки), я б просто зберігав односторонні стосунки з обмеженням перевірки, забезпечуючи, щоб кожен стосунок можна було представляти лише одним способом.

Також я б відкинув сурогатний ідентифікатор і мав замість цього складений ПК (і, можливо, складений унікальний індекс також на перевернутих стовпцях).

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

Ви не кажете запитів, що це ускладнює, але ви завжди можете створити представлення даних

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

Якщо припустити, що "дружба" завжди двостороння / взаємна, я б, мабуть, впорався з цим чимось таким.

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

Результат полягає в тому, що ви змінюєте його на приєднання багатьох до багатьох з "людини" на "особу", на приєднання багатьох до багатьох людей з "людини" на "дружбу". Це спростить приєднання та обмеження, але має побічний ефект, що дозволяє отримати більше двох людей в одній «дружбі» (хоча, можливо, додаткова гнучкість буде потенційною перевагою).

Можливо, вам потрібно буде визначити індекси навколо дружби замість подвоєння кількості рядків:

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

Таким чином, ви подвоюєте сховище для індексів, але не для даних таблиці. Як результат, це має бути 25% економія на диску. Оптимізатор запитів MySQL вибере лише виконувати сканування діапазону індексів, тому тут добре працює концепція покриття індексів.

Ось кілька приємних посилань на покриття індексів:

• 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/

КАВАТИ

Якщо дружба не є взаємною, у вас є підстава для іншого типу відносин: НАЙКРАЩИЙ

Якщо friend_to не є другом friend_of, ви можете просто залишити ці відносини поза столом.

Якщо ви хочете визначити відносини для всіх типів, незалежно від того, є вони взаємними чи ні, ви, ймовірно, можете використовувати такий макет таблиці:

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

З таблиці відносин ви можете впорядкувати відносини, щоб вони включали наступні:

• Друзі повинні бути взаємними
• Недруги можуть бути взаємними чи ні
• Послідовники можуть бути взаємними чи ні
• Інші відносини підлягають тлумаченню (забутим або залишеним або одержувачем помсти (виправлено))
• Посибські стосунки можна продовжити

Це повинно бути більш надійним для всіх відносин, незалежно від того, стосунки взаємні чи ні.

Якщо ви можете в програмі контролювати, що ідентифікатор A завжди нижчий, ніж id B (попереднє замовлення ідентифікаторів елементів A, B), ви можете використовувати запит без АБО (виберіть, де id_A = a AND id_B = b, а не запитувати (id_A = a AND id_B = b) АБО (id_A = b AND id_B = a)), а також підтримувати половину записів, які вам знадобляться, з наближеннями інших. Тоді вам слід використовувати інше поле для підтримки стану відносин (are-friends, a-zaproy-to-b, b-solicited-to-a, exfriends-a, exfriends-b), і ви закінчили.

Це те, як я керував своєю системою дружби, і це спрощує систему і використовує половину рядків, які вам знадобляться для інших систем, лише кажучи, що A дорівнює нижчому значенню id у коді.