मैनेशिया (नोएसक्यूएल) मॉडलिंग को समझने में मेरी सहायता करें

Question

मैनेशिया को समझने के लिए मेरे क्वेस्ट में, मैं अभी भी संबंधपरक शब्दों में सोचने के साथ संघर्ष करता हूं। तो मैं यहां अपने संघर्ष डाल दूंगा और उन्हें हल करने का सबसे अच्छा तरीका मांगूंगा।

एक-से-कई-संबंधों कहो मैं लोगों का एक समूह है,

-record(contact, {name, phone}). 

अब, मुझे पता है कि मैं बहुत से लोगों को हो सकता है हमेशा एक सूची के रूप में बचाया जा करने के लिए फोन परिभाषित कर सकते हैं, एकाधिक फोन नंबर, और मुझे लगता है कि यह करने का तरीका है (है ना? मैं फिर इसे दूसरे नंबर पर कैसे देख सकता हूं, कह सकता हूं, किसी नंबर पर नाम ढूंढना?)। ।

कई-से-अनेक-संबंधों अब मैं कई समूहों मैं में लोगों को रखा जा सकता है लगता है जाने समूह के नाम किसी भी महत्व नहीं है, वे तो बस नाम हैं; अवधारणा "यूनिक्स सिस्टम समूह" या "लेबल" है। भोलेपन से, मैं इस सदस्यता एक proplist के रूप में "संपर्क" रिकॉर्ड के भीतर ऊपर से मॉडल हैं, जैसे

{groups [{friends, bool()}, {family, bool()}, {work, bool()}]} %% and so on... 

एक क्षेत्र के रूप में, उदाहरण के लिए। मैनेशिया के भीतर इसे मॉडल करने का सबसे अच्छा तरीका क्या है यदि मैं समूह के नाम पर समूह के सभी सदस्यों को तुरंत देखने में सक्षम होना चाहता हूं, और यह भी एक समूह में पंजीकृत सभी समूह को देखने में सक्षम होना चाहता हूं? मैं इसे सिर्फ एक सूची के रूप में मॉडल कर सकता हूं जिसमें समूह पहचानकर्ता शामिल हैं। मेनेसिया के साथ उपयोग के लिए, इसे मॉडल करने का सबसे अच्छा तरीका क्या है?

यदि यह प्रश्न गूंगा है तो मैं क्षमा चाहता हूं। मैनेशिया पर बहुत सारे दस्तावेज हैं, लेकिन कुल उपयोग के लिए इसमें कुछ अच्छे उदाहरण हैं (आईएमओ) की कमी है।

Answer 1

पहले उदाहरण के लिए, इस रिकॉर्ड पर विचार करें:

-record(contact, {name, [phonenumber, phonenumber, ...]}). 

contact जहां फोन फोन नंबर की एक सूची है दो क्षेत्रों, name और phone के साथ एक रिकॉर्ड है।चूंकि उपयोगकर्ता 425720 ने कहा कि यदि आप छोटे भंडारण पदचिह्न के लिए अत्यधिक आवश्यकताएं हैं, तो उदाहरण के लिए, यदि तारों की तुलना में इन्हें कुछ और स्टोर करने के लिए समझदारी हो सकती है।

अब यहां वह हिस्सा आता है जो कुंजी-मूल्य स्टोर के साथ "प्राप्त" करना मुश्किल है: आपको व्यस्त संबंधों को भी स्टोर करने की आवश्यकता है। दूसरे शब्दों में, आप के लिए कुछ इसी तरह की जरूरत है निम्नलिखित:

-record(phone, {phonenumber, contactname}). 

आप सार दूर डेटाबेस से निपटने के लिए अपने आवेदन में एक परत है, तो आप यह हमेशा/जोड़ने जब जोड़ने/संपर्क बदलते फोन रिकॉर्ड बदलने बना सकता है ।

-

दूसरा उदाहरण के लिए, इन दो रिकॉर्ड पर विचार करें:

-record(contact, {uuid, name, [group_id, group_id]}). 
-record(group, {uuid, name, [contact_id, contact_id]}). 

सबसे आसान तरीका सिर्फ संबंधित अभिलेखों की ओर इशारा करते आईडी स्टोर करने के लिए है। चूंकि मेनेसिया में रेफरेंसियल अखंडता की कोई अवधारणा नहीं है, इसलिए यदि आप उदाहरण के लिए सभी समूहों से उस समूह को हटाए बिना समूह को हटाते हैं तो यह सिंक से बाहर हो सकता है।

आप संपर्क रिकॉर्ड पर समूह के प्रकार स्टोर करने के लिए की जरूरत है, तो आप निम्न का उपयोग कर सकते:

-record(contact, {name, [{family, [group_id, group_id]}, {work, [..]}]}). 

-

आपकी दूसरी समस्या यह भी एक मध्यवर्ती रिकॉर्ड का उपयोग करके हल किया जा सकता, जिसे आप "सदस्यता" के रूप में सोच सकते हैं।

-record(contact, {uuid, name, ...}). 
-record(group, {uuid, name, ...}). 
-record(membership, {contact_uuid, group_uuid}). # must use 'bag' table type 

कोई भी "सदस्यता" रिकॉर्ड हो सकता है। प्रत्येक उपयोगकर्ता समूह के लिए एक रिकॉर्ड होगा।

Answer 2

सबसे पहले, आप कुंजी-मूल्य स्टोर डिज़ाइन पैटर के लिए पूछते हैं। पूरी तरह से ठीक। इससे पहले कि मैं आपके प्रश्न का उत्तर देने की कोशिश करूंगा, इसे स्पष्ट करें - मेनेसिया क्या है। यह के-वी डीबी है, जिसे ओटीपी में शामिल किया गया है। क्योंकि यह मूल है, यह Erlang से उपयोग करने में बहुत सहज है। लेकिन सावधान रहना। यह पुराना डेटाबेस है जिसमें बहुत प्राचीन धारणाएं हैं (उदाहरण के लिए रैखिक हैशिंग के साथ डेटा वितरण)। तो आगे बढ़ें, सीखें और इसके साथ खेलें, लेकिन उत्पादन के लिए अपना समय लें और अपनी जरूरतों के लिए सर्वश्रेष्ठ खोजने के लिए नोएसQL दुकान ब्राउज़ करें।

@telephone उदाहरण। स्ट्रिंग्स (सूची()) के रूप में सामान को स्टोर न करें - यह जीसी के लिए बहुत भारी है। मैं फोन_1 :: < < बाइनरी>>, फोन_2 :: < < बाइनरी>>, फोन_क्स्ट्रा :: [< < बाइनरी>>] और सबसे लगातार क्वेरी-फील्ड पर इंडेक्स बनाएं। इसके अलावा मेनेसिया इंडस्ट्रीज मुश्किल हैं - जब नोड दुर्घटनाग्रस्त हो जाता है और ऊपर जाता है, तो उन्हें खुद को पुनर्निर्माण करने की आवश्यकता होती है (इसमें बहुत समय लग सकता है)।

@family उदाहरण। फ्लैट नामस्थान के साथ यह काफी मुश्किल है। आप अधिक जटिल कुंजी के साथ खेल सकते हैं .. शायद ग्रुप के लिए अलग टेबल बनाएं और सदस्यों के पहचानकर्ता रखें? या प्रत्येक सदस्य के समूह के समूह होंगे जो वह संबंधित हैं (बनाए रखने के लिए मुश्किल ..)। यदि आप दोस्तों को पहचानना चाहते हैं तो मैं डेटा प्रस्तुत करने से पहले कुछ प्रकार के अनुबंध को लागू करूंगा (ए बी का दोस्त आईएफएफ बी ए के दोस्त है) - यह दृष्टिकोण डेटा में अंतिम स्थिरता और संघर्षों का सामना करेगा।