2010-02-09 10 views
6

मैं मोंगोडीबी और कॉच डीबी को गंभीर प्रयास देने के लिए तैयार हूं। अब तक मैंने मोंगो के साथ थोड़ा सा काम किया है, लेकिन मैं सोफे के रीस्टफुल दृष्टिकोण से भी चिंतित हूं।नो-एसक्यूएल संबंध प्रश्न

संबंध डीबी के साथ सालों से काम करने के बाद, मुझे अभी भी यह नहीं मिला कि गैर-रिलेशनल डेटाबेस के साथ कुछ चीजें करने का सबसे अच्छा तरीका क्या है।

उदाहरण के लिए, यदि मेरे पास 1000 कार की दुकानें और 1000 कार प्रकार हैं, तो मैं यह निर्दिष्ट करना चाहता हूं कि प्रत्येक दुकान किस प्रकार की कार बेचती है। प्रत्येक कार में 100 विशेषताएं होती हैं। एक रिलेशनल डेटाबेस के भीतर मैं प्रत्येक कार की दुकान को आईडी प्रकार के माध्यम से बेचने वाले कार प्रकारों से जोड़ने के लिए एक मध्यम तालिका बनाउंगा। नो-एसक्यूएल का दृष्टिकोण क्या है? यदि हर कार की दुकान 50 कार प्रकार बेचती है, तो इसका मतलब है कि मुझे बड़ी मात्रा में डेटा की प्रतिलिपि बनाना है, अगर मुझे कार की दुकान में स्टोर करना है तो वह सभी कार प्रकारों की सभी सुविधाओं को बेचता है!

किसी भी मदद की सराहना की।

उत्तर

0

देखने के एक HBase/बिगटेबल बिंदु से आ रहा है, आम तौर पर आप पूरी तरह से अपने डेटा denormalize, और एक "सूची" क्षेत्र, या बहुआयामी नक्शा स्तंभ (एक बेहतर विवरण के लिए इस link देखें) का प्रयोग करेंगे।

शब्द "कॉलम" एक और लोड शब्द "तालिका" और "आधार" की तरह जो साल आरडीबीएमएस अनुभव के के भावनात्मक सामान वहन करता है।

इसके बजाय, मुझे को एक बहुआयामी मानचित्र के बारे में सोचना आसान लगता है - यदि आप करेंगे तो नक्शे का नक्शा।

कई उदाहरणों के लिए आपके उदाहरण के लिए, आप अभी भी दो टेबल बना सकते हैं, और तालिकाओं के बीच संबंध रखने के लिए अपने multidimenstional मानचित्र कॉलम का उपयोग कर सकते हैं।

Hadoop/HBase FAQ में पूछे जाने वाले प्रश्न प्रश्न 20 देखें:

प्रश्न: [माइकल Dagaev] कैसे आप एक HBase तालिका कई-से-अनेक संघ के लिए दो संस्थाओं के बीच, के लिए डिजाइन हैं उदाहरण छात्र और पाठ्यक्रम?

मैं दो तालिकाओं को परिभाषित करेगा: छात्र: छात्र आईडी छात्र डेटा (नाम, पता, ...) कोर्स पाठ्यक्रम (स्तंभ क्वालिफायर यहाँ के रूप में उपयोग पाठ्यक्रम आईडी): बेशक आईडी पाठ्यक्रम डेटा (नाम, पाठ्यक्रम , ...) छात्र (यहां छात्र आईडी को कॉलम क्वालीफायर के रूप में उपयोग करें) क्या यह समझ में आता है?

ए [जोनाथन ग्रे]: आपका डिजाइन समझ में आता है। जैसा कि आपने कहा था, आप में शायद में छात्र और पाठ्यक्रम तालिकाओं में से दो कॉलम-परिवार होंगे। डेटा के लिए एक, दूसरा छात्र या पाठ्यक्रम के कॉलम के साथ। उदाहरण के लिए, छात्र पंक्ति देख सकती है जैसे: छात्र: आईडी/पंक्ति/कुंजी = 1001 डेटा: नाम = छात्र का नाम डेटा: पता = 123 एबीसी सेंट पाठ्यक्रम: 2001 = (यदि आपको इस एसोसिएशन के बारे में अधिक जानकारी चाहिए , उदाहरण के लिए, यदि वे प्रतीक्षा सूची पर हैं) पाठ्यक्रम: 2002 = ...यह स्कीमा आपको प्रश्नों के लिए तेजी से पहुंच प्रदान करता है, छात्र (छात्र तालिका, पाठ्यक्रम परिवार) के लिए सभी कक्षाएं, या कक्षा (पाठ्यक्रम तालिका, छात्र परिवार) के लिए सभी छात्रों को दिखाएं।

+0

मुझे लगता है कि हम कई से कई रिश्तों के बारे में बात कर रहे हैं, जो कि कई से अधिक रिश्ते नहीं हैं। प्रत्येक कार प्रकार में बहुत सारी सुविधाएं होती हैं और प्रत्येक दुकान कई कार प्रकार बेच सकती है। – Theo

1

मोंगोडीबी में अक्सर इस्तेमाल किया जाने वाला दृष्टिकोण प्रत्येक कार की दुकान में कार प्रकारों के _ids की एक सूची स्टोर करेगा। तो तालिका में कोई अलग शामिल नहीं है लेकिन फिर भी मूल रूप से क्लाइंट-साइड में शामिल हो रहा है।

एम्बेडेड दस्तावेज़ ऐसे मामलों के लिए अधिक प्रासंगिक हो जाते हैं जो इस तरह के कई नहीं हैं।

3

मैं केवल कॉच डीबी से बात कर सकता हूं।

डीबी में अपना डेटा चिपकाने का सबसे अच्छा तरीका यह है कि इसे जेएसओएन में परिवर्तित करने से परे इसे सामान्यीकृत न करें। यदि वह डेटा "कार" है तो डेटाबेस में प्रत्येक कार के बारे में सभी डेटा चिपकाएं।

फिर आप डेटा का सामान्यीकृत सूचकांक बनाने के लिए मानचित्र/कम उपयोग करते हैं। इसलिए, यदि आप प्रत्येक कार की एक इंडेक्स चाहते हैं, तो दुकान द्वारा पहले क्रमबद्ध करें, फिर कार-प्रकार से आप प्रत्येक कार को [दुकान, कार-प्रकार] के सूचकांक से उत्सर्जित करेंगे।

मानचित्र कम पहली बार थोड़ा डरावना प्रतीत होता है, लेकिन आपको सभी जटिल चीजों या यहां तक ​​कि btrees को समझने की आवश्यकता नहीं है, आपको यह समझने की आवश्यकता है कि कुंजी सॉर्टिंग कैसे काम करती है।

http://wiki.apache.org/couchdb/View_collation

कि अकेले आप भिन्न नक्शे के साथ दस्तावेजों CouchDB में प्रणाली को कम से अधिक अद्भुत सामान्यीकृत अनुक्रमणिका बना सकते हैं के साथ

0

संबंधपरक डेटाबेस में, अवधारणा बहुत स्पष्ट है: "car_id, car_type, car_name, car_price" जैसे स्तंभों वाली कारों के लिए एक तालिका, और कॉलम "shop_id, car_id, shop_name, sale_count" के साथ दुकानों के लिए एक और तालिका, " car_id "डेटा ओपीएस के लिए दो टेबल एक साथ जोड़ता है। सभी कॉलम डेटाबेस बनाने में अच्छी तरह परिभाषित होना चाहिए।

कोई SQL डेटाबेस सिस्टम आपको इन कॉलम और तालिकाओं को पूर्व-परिभाषित करने की आवश्यकता नहीं है। तुम सिर्फ एक निश्चित प्रारूप में अपने रिकॉर्ड का निर्माण, का कहना है कि JSON, जैसे:

"{car:[id:1, type:auto, name:ford], shop:[id:100, name:some_shop]}", 
"{car:[id:2, type:auto, name:benz], shop:[id:105, name:my_shop]}", 
..... 

आपके सिस्टम के बाद ऑन-लाइन है अपने प्रबंधन के लिए सेवा प्रदान करने के लिए, आप डाटाबेस संरचना के अपने डिजाइन में कुछ खामियां देखते हैं मिल सकता है आप, अपने भविष्य के रिकॉर्ड के लिए "दुकान" के एक कॉलम "कर्मचारी" को जोड़ने की उम्मीद है। फिर आपके नए रिकॉर्ड आ रहे हैं:

"{car:[id:3, type:auto, name:RR], shop:[id:108, name:other_shop, employee:Bill]}", 

कोई SQL सिस्टम आपको ऐसा करने की अनुमति नहीं देता है, लेकिन इस नौकरी के लिए डेटाबेस का संबंध असंभव है।