वहाँ एक दोहरी संबंध स्टोर करने के लिए एक सुंदर तरीका है (यानी 1 उपयोगकर्ता और 2 उपयोगकर्ता दोस्त हैं)

Question

मैं इस महीने के काम के दो अलग-अलग टुकड़ों में एक ही समस्या हुई:

Version 1: User 1 & User 2 are friends 
Version 2: Axis 1 & Axis 2 when graphed should have the quadrants colored... 

समस्या है , मुझे इस जानकारी को स्टोर और क्वेरी करने के लिए आरडीबीएमएस का उपयोग करके एक सुरुचिपूर्ण तरीका नहीं दिख रहा है।

दृष्टिकोण: 1:

दो स्पष्ट दृष्टिकोण हैं

store the information twice (i.e. two db rows rows per relationship): 
u1, u2, true 
u2, u1, true 
u..n, u..i, true 
u..i, u..n, true 

have rules to always look for the inverse on updates: 
on read, no management needed 
on create, create inverse 
on delete, delete inverse 
on update, update inverse 

Advantage: management logic is always the same. 
Disadvantage: possibility of race conditions, extra storage (which is admittedly cheap, but feels wrong) 

दृष्टिकोण 2:

store the information once (i.e. one db row per relationship) 
u1, u2, true 
u..n, u..i, true 

have rules to check for corollaries: 
on read, if u1, u2 fails, check for u2, u1 
on create u1, u2: check for u2, u1, if it doesn't exist, create u1, u2 
on delete, no management needed 
on update, optionally redo same check as create 

Advantage: Only store once 
Disadvantage: Management requires different set of cleanup depending on the operation 

वहाँ एक 3 दृष्टिकोण है कि की तर्ज पर चला जाता है कि अगर मैं सोच रहा हूँ " एफ (एक्स, वाई) का उपयोग करके कुंजी जहां एफ (एक्स, वाई) प्रत्येक एक्स, वाई संयोजन के लिए अद्वितीय है और जहां एफ (एक्स, वाई) === एफ (वाई, एक्स) "

मेरा आंत मुझे बताता है कि बिटवाई ऑपरेशंस का कुछ संयोजन होना चाहिए जो इन आवश्यकताओं को पूरा कर सके। एक दो-स्तंभ की तरह कुछ:

कुंजी 1 = एक्स & & y कुंजी 2 = x + y

मैं आशा करती हूं कि जो लोग समाजशास्त्र विभाग में कम समय गणित विभाग में अधिक समय बिताया है, और इसकी संभावना या असंभवता का सबूत देखा गया है और यह एक त्वरित "[आप मूर्ख,] आसानी से साबित (आईएम) प्रदान कर सकता है, यह लिंक देखें" (नाम वैकल्पिक नाम)

कोई अन्य सुरुचिपूर्ण दृष्टिकोण भी बहुत होगा स्वागत हे।

धन्यवाद

Answer 1

वहाँ भी एक अतिरिक्त बाधा जोड़कर 2 दृष्टिकोण का उपयोग करने का तरीका है। जाँच करें कि u1 < u2:

CREATE TABLE User 
(Name VARCHAR(10) NOT NULL 
, PRIMARY KEY (Name) 
) ; 

CREATE TABLE MutualFriendship 
(u1 VARCHAR(10) NOT NULL 
, u2 VARCHAR(10) NOT NULL 
, PRIMARY KEY (u1, u2) 
, FOREIGN KEY (u1) 
    REFERENCES User(Name) 
, FOREIGN KEY (u2) 
    REFERENCES User(Name) 
, CHECK (u1 < u2) 
) ; 

नियमों को पढ़ने, बनाने के लिए, सम्मिलित या अद्यतन (LEAST(u1,u2), GREATEST(u1,u2)) का उपयोग करना होगा करने के लिए। हालांकि

#Python, returns 3 tuple 
def get_hash(x, y): 
    return (x & y, x | y, x * y) 

मैं इसे साबित नहीं कर सकते,:

Answer 2

आप, यदि यह मामला है तो मैं U1, U2 यू 2, U1 U3, अशक्त U4, यू 5 यू 5 की तरह कुछ का प्रयोग करेंगे 1. करने के लिए दोस्तों की संख्या को सीमित करने लगते हैं u4

u3 में कोई मित्र नहीं है।

Answer 3

एसक्यूएल में यह आपकी पहली दृष्टिकोण का समर्थन करने के बाधाओं को लागू करना आसान है:

CREATE TABLE MutualFriendship 
(u1 VARCHAR(10) NOT NULL, 
u2 VARCHAR(10) NOT NULL, 
PRIMARY KEY (u1,u2), 
FOREIGN KEY (u2,u1) REFERENCES MutualFriendship (u1,u2)); 

INSERT INTO MutualFriendship VALUES 
('Alice','Bob'), 
('Bob','Alice'); 

Answer 4

किसी को दिलचस्पी रखता है के लिए, मैं कुछ बिटवाइज़ संचालन के साथ चारों ओर खेला और पाया कि निम्नलिखित च (एक्स, वाई) के लिए मानदंडों को पूरा करने लगता है ।

Answer 5

"x y का मित्र है"।

(x, y) जोड़े की एक तालिका परिभाषित करें और एक कैनोलिक रूप लागू करें, उदा। एक्स < वाई।इससे यह सुनिश्चित होगा कि आपके डेटाबेस में दोनों (पी, क्यू) और (क्यू, पी) नहीं हो सकते हैं, इस प्रकार यह "एक बार स्टोर" सुनिश्चित करेगा।

मित्रों के चयन के रूप में एक दृश्य बनाएं, मित्र संघ से एक्स को वाई के रूप में एक्स, वाई दोस्तों के रूप में एक्स के रूप में चुनें।

आधार तालिका के विरुद्ध अपने अपडेट करें (नकारात्मक: अद्यतनकर्ताओं को लागू किए गए कैननिकल रूप से अवगत होना चाहिए), दृश्य के विरुद्ध अपने प्रश्न पूछें।