Arkadaşlık için nasıl bir ilişki tablosu tasarlamalıyım?

Eğer Abir arkadaşım B, o zaman ben her iki değeri saklamak gerekir ABve BAya bir tane yeter? Her iki yöntemin avantaj ve dezavantajları nelerdir?

İşte gözlemim:

• İkisini de tutarsam, bir arkadaşımdan bir istek aldığımda ikisini de güncellemem gerekir.
• Her ikisini de tutmazsam, o zaman JOINbu tabloyla çoklu yapmak zorunda kalırken zor buldum .

Şu anda ilişkiyi bir yönden sürdürüyorum.

Peki bu durumda ne yapmalıyım? Herhangi bir tavsiye?

AB ve BA’yı saklardım. Bir arkadaşlık gerçekten iki yönlü bir ilişkidir, her varlık bir başkasıyla bağlantılıdır. Sezgisel olarak "dostluğu" iki insan arasında tek bir bağlantı olarak düşünmemize rağmen, ilişkisel açıdan "A'nın bir arkadaşı B var" ve "B'nin arkadaşı A" gibi olduğunu düşünüyorum. İki ilişki, iki kayıt.

Arkadaşlığın simetrik olması isteniyorsa (yani A arkadaş olması mümkün değil Bama tersi olmasa da), o zaman her ilişkinin sadece bir şekilde temsil edilebildiğinden emin olmak için bir kontrol kısıtlamasıyla tek yönlü bir ilişkiyi saklardım.

Ayrıca vekil kimliğini hendek ve bunun yerine bileşik bir PK (ve muhtemelen ters sütunlarda da bileşik bir benzersiz dizin) olur.

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

Bunu zorlaştıran sorguları söylemiyorsunuz, ancak her zaman bir Görünüm oluşturabilirsiniz.

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

Bir "arkadaşlığın" her zaman iki yönlü / karşılıklı olduğunu varsayarsak, muhtemelen bunun gibi bir şeyle uğraşırdım.

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

Sonuç olarak, bunu "kişiden" kişiye "kişiden", "kişiden" ye "çoktan çoğa" birleşimine, "kişiliğe" kadar "arkadaşlık" olarak değiştirirsiniz. Bu, katılımları ve kısıtlamaları basitleştirecek, ancak ikiden fazla kişiye tek bir "dostlukta" izin vermenin yan etkisine sahip (belki de ek esneklik potansiyel bir avantaj olabilir).

Sıra sayısını ikiye katlamak yerine arkadaşlıkların etrafındaki dizinleri tanımlamanız gerekebilir:

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

Bu şekilde, dizinler için depolama alanını ikiye katlarsınız, ancak tablo verileri için değil. Sonuç olarak, bu, disk alanında% 25'lik bir tasarruf olmalıdır. MySQL Query Optimizer yalnızca indeks aralığı taramalarını gerçekleştirmeyi seçecektir, bu nedenle indeks indeksleri kavramı burada iyi çalışır.

İşte Kapak Dizinleri ile ilgili bazı güzel linkler:

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

UYARI

Eğer arkadaşlık karşılıklı değilse, başka tür bir ilişki için temeliniz vardır: FOLLOWER

Friend_to bir friend_of arkadaşı değilse, bu ilişkiyi masanın dışında bırakabilirsiniz.

Tüm türler için ilişkileri tanımlamak istiyorsanız, karşılıklı olsun veya olmasın, muhtemelen aşağıdaki tablo düzenini kullanabilirsiniz:

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

İlişki tablosundan, aşağıdakileri içerecek şekilde ilişkileri düzenleyebilirsiniz:

• Arkadaşlar karşılıklı olmalı
• Düşmanlar karşılıklı olabilir veya olmayabilir
• Takipçiler karşılıklı olabilir ya da olmayabilir
• Diğer ilişkiler, değerlendirmeye tabi tutulacaktı (unutulmuş, terk edilmiş veya intikam alıcısı tarafından) (sabit)
• Olası ilişkiler daha da genişletilebilir

İlişkinin karşılıklı olup olmadığına bakılmaksızın, bu tüm ilişkiler için daha sağlam olmalıdır.

Uygulama içinde A'nın kimliğinin her zaman B'nin id'sinden düşük olduğunu kontrol edebilirseniz (A, B elementlerinin kimliklerini ön sipariş edin) VEYA olmadan sormadan yararlanabilirsiniz (sormak yerine id_A = a AND id_B = b'yi seçin) (id_A = a AND id_B = b) VEYA (id_A = b AND id_B = a)) ve ayrıca diğerinin yaklaşımlarıyla ihtiyaç duyacağınız kayıtların yarısını da saklayın. Öyleyse, ilişkinin durumunu korumak için başka bir alan kullanmalısınız (arkadaşlar, arkadaşlara, b'ye davet, arkadaşlara, arkadaşlara, b-arkadaşlara, b) ve bitirdiniz.

Bu benim arkadaşlık sistemimi yönetme şeklimdir ve sistemi basitleştirir ve diğer sistemlerde ihtiyaç duyacağınız satırın yarısını kullanır, sadece A kodundaki düşük id değerine eşittir.