Как мне составить таблицу отношений для дружбы?

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

Вот мое наблюдение:

• Если я сохраню оба, я должен обновить оба, когда получу запрос от друга.
• Если я не сохраню оба, то мне будет трудно, когда приходится делать несколько JOINс этой таблицей.

В настоящее время я поддерживаю отношения в одном направлении.

Так что мне делать в этом случае? Любой совет?

Я хотел бы хранить AB и BA. Дружба - это двусторонние отношения, каждая сущность связана с другой. Хотя интуитивно мы думаем о «дружбе» как об одной связи между двумя людьми, с точки зрения отношений это больше похоже на «А имеет друга Б» и «Б имеет друга А». Два отношения, две записи.

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

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

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 Query Optimizer выберет только выполнять сканирование диапазона индекса, поэтому концепция покрытия индексов здесь работает хорошо.

Вот несколько хороших ссылок по индексам покрытия:

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

ПРЕДОСТЕРЕЖЕНИЕ

Если дружба не взаимна, у вас есть основание для другого типа отношений: FOLLOWER

Если 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 всегда ниже, чем идентификатор B (предварительный порядок идентификаторов элементов A, B), вы можете использовать запрос без ИЛИ (выберите где id_A = a И id_B = b вместо запроса (id_A = a AND id_B = b) ИЛИ (id_A = b AND id_B = a)), а также ведите половину записей, которые вам понадобятся, с приближениями других. Затем вы должны использовать другое поле, чтобы поддерживать состояние отношений («друзья», «a-solicited-to-b», «b-solicited-to-a», «exfriends-a», «exfriends-b»), и все готово.

Так я управлял своей системой дружбы, и это упрощает систему и использует половину строк, которые вам понадобятся в других системах, только говоря, что A равно нижнему значению id в коде.