अनेक संबंध

Question

के लिए कई सममित प्रतिनिधित्व करने के लिए मैं कैसे एक इकाई कहा जाता है उपयोगकर्ता और एक रिश्ता दोस्ती मान लीजिए दो उपयोगकर्ताओं के लिए तो मैं एक मेज 'उपयोगकर्ता' और एक रिश्ता तालिका 'दोस्ती'

 

USER 
id firstName LastName 
1 taher  chhabrawala 
2 john  Dsouza 
3 rahul  singh 
4 deepak patel
 

Friendship 
id id 
1  2 
1  3 
1  4 
4  1 
4  3
 

है के बीच मौजूद

उपर्युक्त तालिका में मैं एक ही सूचना के संचय कर रहा हूँ दो बार यानी

"ताहिर दीपक और दीपक के एक दोस्त ताहिर के एक दोस्त है कि" वहाँ किसी भी तरह से इस अतिरेक को कम करने के है?

Answer 1

ठीक है, आप निश्चित रूप से यह मान सकते हैं कि सभी दोस्ती सममित हैं और केवल दो बार उस मित्रता को स्टोर करते हैं, लेकिन इसका मतलब यह होगा कि जब आप ताहर के सभी दोस्तों के लिए पूछना चाहते हैं, तो आपको किसी भी कॉलम में अपनी आईडी देखना होगा।

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

User     
Id Name   
1  Taher   
2  Deepak   

Relationship    
Id  StartDate   
1  2010-08-23 

UserRelationship 
RelationshipId UserId 
1    1 
1    2 

दूसरी ओर, फेसबुक पर, उदाहरण के लिए, मैं किसी को "दोस्त" कर सकता हूं और वे मुझे वापस दोस्त न करने का फैसला कर सकते हैं। यदि आपके पास अब "अनावश्यक" दृष्टिकोण नहीं है जिसका आप अब उपयोग कर रहे हैं, तो आप इस बात का प्रतिनिधित्व कैसे करेंगे कि अभी तक पारस्परिक दोस्ती नहीं है?

Answer 2

स्पष्ट समाधान मित्रों की प्रत्येक जोड़ी प्रति केवल 1 रिकॉर्ड स्टोर करना है। हालांकि, यह विशिष्टता बनाए रखने के लिए कठिन बनाता है; मित्र संबंधों को प्राप्त करने/अपडेट करने/हटाने के लिए सभी प्रश्न "अनावश्यक" समाधान की तुलना में अधिक जटिल हो जाते हैं। साथ ही, 2 रिकॉर्ड्स के साथ समाधान आपको मित्रों के अनुरोधों को बनाए रखने की अनुमति देता है (उदा।, उपयोगकर्ता ए उपयोगकर्ता को मित्र बनने के लिए कहता है। उपयोगकर्ता बी इस अनुरोध की पुष्टि या अस्वीकार कर सकता है)। तो मैं कहूंगा कि इस मामले में अनावश्यकता पूरी तरह मान्य है।

Answer 3

'पहला आईडी मान हमेशा दूसरे आईडी मान से कम है' जैसे नियम बनाएं, ताकि आप सुनिश्चित कर सकें कि कोई डुप्लिकेट नहीं है।

उस स्थिति में, जोड़ी (4,1) अमान्य है, और जोड़ी (4,3) को (3,4) के रूप में संग्रहीत किया जाएगा।

Answer 4

यदि आपने सममित डिजाइन का उपयोग करने का निर्णय लिया है तो यह सुनिश्चित करने के लिए उपयोगी हो सकता है कि हर दोस्ती हमेशा द्विपक्षीय है। आप इस कोशिश कर सकते हैं:

CREATE TABLE Friendship 
(UserId1 INT NOT NULL REFERENCES Users (UserId), 
    UserId2 INT NOT NULL, 
    PRIMARY KEY (UserId1, UserId2), 
    FOREIGN KEY (UserId2, UserId1) REFERENCES Friendship (UserId1, UserId2)); 

Answer 5

आप दो पंक्तियों की दुकान हैं, तो आप एक अखंडता नियम है कि सुनिश्चित करता है कि दोस्ती हमेशा जोड़े में आ लागू करने के लिए आवश्यक हो जाएगा। तालिका में

स्टोर केवल एक पंक्ति (जैसे कि, एफआर), और जैसा कि

चयन एक्स एक दृश्य SYMFR एफआर से यूनिअन एफआर