友情のためにリレーションシップテーブルを設計するにはどうすればよいですか？

のA友人であればB、値ABとの両方を保存する必要BAがありますか、それとも1つで十分ですか？両方の方法の長所と短所は何ですか。

私の観察は次のとおりです。

• 両方を保持する場合、友人からリクエストを受け取ったときに両方を更新する必要があります。
• 両方を保持しないJOINと、このテーブルで複数の作業を行う必要があるときに困難を感じました。

現在、私は関係を一方向に維持しています。

この場合、どうすればよいですか？何かアドバイス？

ABとBAを保存します。友情は実際には双方向の関係であり、各エンティティは別のエンティティにリンクされています。直感的には、「友情」は2人の人間の1つのリンクであると考えていますが、リレーショナルの観点からは、「Aには友人Bがいます」、「Bには友人Aがいます」に似ています。2つの関係、2つのレコード。

友情が対称的であることを意図している場合（つまり、 A 友達となるBその逆はできません）、チェック関係を使用して一方向の関係を保存します。

また、サロゲートIDを捨てて、代わりに複合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)
)

その結果、多対多の結合から「人」から「人」に、多対多の結合から「人」から「友情」に変更されます。これにより、結合と制約が簡素化されますが、1人の「友情」で3人以上を許可するという副作用があります（ただし、追加の柔軟性が潜在的な利点になります）。

行数を2倍にする代わりに、友情の周りにインデックスを定義する必要がある場合があります。

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

この方法では、テーブルデータではなく、インデックスのストレージを2倍にします。その結果、これによりディスクスペースが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/

警告

友情が相互関係でない場合、別のタイプの関係の基礎があります。フォロワー

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

関係テーブルから、以下を含むように関係を調整できます。

• 友人は相互に
• 敵は相互かそうでないか
• フォロワーは相互かそうでないか
• その他の関係は、解釈の対象となります（忘れられた、見捨てられた、または復ofの受信者（修正済み））
• 可能性のある関係をさらに拡張できます

これは、関係が相互であるかどうかに関係なく、すべての関係に対してより堅牢である必要があります。

アプリケーション内でAのidが常にBのidより小さいことを制御できる場合（A、B要素のidを事前に注文）、ORなしで尋ねることを活用できます（尋ねる代わりにid_A = a AND id_B = bを選択します） （id_A = a AND id_B = b）OR（id_A = b AND id_B = a））、また、他の近似で必要なレコードの半分を維持します。次に、別のフィールドを使用して関係の状態を維持する必要があります（are-friends、a-solicited-to-b、b-solicited-to-a、exfriends-a、exfriends-b）、これで完了です。

これが私のフレンドシップシステムの管理方法です。これにより、システムが簡素化され、他のシステムで必要な行の半分が使用されます。