Como devo criar uma tabela de relacionamento para amizade?

Se Aé amigo B, devo guardar os dois valores ABe BA, ou um é suficiente? Quais são as vantagens e desvantagens de ambos os métodos.

Aqui está minha observação:

• Se eu mantiver os dois, preciso atualizá-los quando receber uma solicitação de um amigo.
• Se eu não mantiver os dois, será difícil ter que fazer vários JOINcom esta tabela.

Atualmente, mantenho o relacionamento de uma maneira.

Então, o que devo fazer neste caso? Algum conselho?

Eu armazenaria AB e BA. Uma amizade é realmente um relacionamento de mão dupla, cada entidade está ligada a outra. Embora intuitivamente pensemos na "amizade" como um elo entre duas pessoas, do ponto de vista relacional, é mais como "A tem um amigo B" e "B tem um amigo A". Dois relacionamentos, dois registros.

Se a amizade tiver a intenção de ser simétrica (ou seja, não é possível A ser amiga, Bmas não vice-versa), eu armazenaria apenas o relacionamento unidirecional com uma restrição de verificação, garantindo que cada relacionamento possa ser representado apenas de uma maneira.

Também abandonaria o ID substituto e, em vez disso, teria uma PK composta (e possivelmente um índice exclusivo composto também nas colunas invertidas).

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

Você não diz as consultas que dificultam, mas sempre pode criar uma Visualização

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

Supondo que uma "amizade" seja sempre bidirecional / mútua, eu provavelmente lidaria com algo assim.

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

O resultado é que você muda de uma associação muitos para muitos de "pessoa" para "pessoa", para uma associação muitos para muitos de "pessoa" para "amizade". Isso simplificará junções e restrições, mas tem o efeito colateral de permitir mais de duas pessoas em uma única "amizade" (embora talvez a flexibilidade adicional seja uma vantagem potencial).

Pode ser necessário definir índices em torno de amizades, em vez de dobrar o número de linhas:

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

Dessa forma, você duplica o armazenamento para índices, mas não para os dados da tabela. Como resultado, isso deve economizar 25% no espaço em disco. O MySQL Query Optimizer escolherá executar apenas varreduras de intervalo de índice, razão pela qual o conceito de cobertura de índices funciona bem aqui.

Aqui estão alguns links interessantes sobre Cobertura de índices:

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

EMBARGO

Se a amizade não é mútua, você tem a base para outro tipo de relacionamento: SEGUINTE

Se friend_to não for amigo de friend_of, você pode simplesmente deixar esse relacionamento fora da tabela.

Se você deseja definir relacionamentos para todos os tipos, sejam eles mútuos ou não, provavelmente você pode usar o seguinte layout de tabela:

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

Na tabela de relações, você pode organizar os relacionamentos para incluir o seguinte:

• Amigos devem ser mútuos
• Os inimigos podem ser mútuos ou não
• Os seguidores podem ser mútuos ou não
• Os outros relacionamentos estariam sujeitos à interpretação (pelo esquecido ou abandonado ou pelo destinatário de vingança (fixo))
• Possíveis relacionamentos podem ser ampliados

Isso deve ser mais robusto para todos os relacionamentos, seja o relacionamento mútuo ou não.

Se você pode controlar dentro do aplicativo que o ID de A é sempre menor que o ID de B (pré-ordena os IDs dos elementos A, B), você pode pedir sem um OR (selecione onde id_A = a AND id_B = b, em vez de perguntar (id_A = a AND id_B = b) OR (id_A = b AND id_B = a)), e também mantenha metade dos registros necessários com as aproximações dos outros. Em seguida, você deve usar outro campo para manter o estado do relacionamento (são-amigos, a-solicitado-a-b, b-solicitado-a-a, ex-amigos-a, ex-amigos-b) e pronto.

Esta é a maneira como eu gerenciei meu sistema de amizade, e isso simplifica o sistema e usa metade das linhas que você precisará com outros sistemas, apenas dizendo que A é igual ao menor valor de ID no código.