"मास्टर" सहयोगी तालिका?

Question

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

इस मॉडल कई साहचर्य टेबल आम तौर पर मौजूद होगा, उदाहरण के लिए, client_contact, contract_addr, contact_phone, contact_email, SERVICE_PROVIDER, service_consumer में, आदि

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

यह मेरे लिए हुआ हालांकि: सभी संगठनों को रखने वाला एक "मास्टर" सहयोगी तालिका क्यों नहीं है? इसके लिए इस मास्टर टेबल को दो पीके के अलावा "एसोसिएशन टाइप" होना चाहिए, और सभी पीके के लिए एक ही प्रकार (इन्ट्स, GUIDs इत्यादि) होना चाहिए।

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

मुझे लगता है कि इस दृष्टिकोण का वर्णन करने वाला एक पैटर्न (या विरोधी पैटर्न) हो सकता है, लेकिन ऑनलाइन कुछ भी नहीं मिला है। क्या किसी ने कोशिश की है? यदि हां, तो क्या यह स्केल करता है?

आपके द्वारा प्रदान किए जा सकने वाले किसी भी संदर्भ की सराहना की जाएगी।

Answer 1

जो आप वर्णन कर रहे हैं वह मुझे डेटा वेयरहाउसिंग से तथ्यों की याद दिलाता है। मेरी समझ यह है कि आप प्रत्येक-से-कई रिश्तों को मॉडल करने के लिए एक टेबल के साथ एक ठेठ लेनदेन स्कीमा से शुरू करते हैं। फिर, आसान आयामी विश्लेषण के लिए डेटा को पुन: स्थापित करने के लिए, आप अपनी स्कीमा में कुछ/सभी रिश्तों को एक विस्तृत तालिका में एकत्र कर सकते हैं जहां प्रत्येक कॉलम एक कुंजी है। यह प्रभावी ढंग से समय से पहले सभी संभव जुड़ता है और उन्हें एक मेज में डंप करता है, जो आपकी संस्थाओं के गुणों को प्राप्त करने के बाद संबंधों से पूछताछ में शामिल होता है।

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

Answer 2

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

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

तीसरा, प्रत्येक क्वेरी को शायद पंक्तियों की कुल संख्या तक पहुंचने की आवश्यकता है, भले ही वे एकाधिक तालिकाओं में से एक हैं या एक। इसलिए, जब तक कि आप अपने डेटा के बारे में कुछ नहीं जानते हैं जो आपको क्लस्टर इंडेक्स या कुछ बनाने देगा, तो आप क्वेरी चलाने पर शायद पृष्ठों की एक ही संख्या को पुनर्प्राप्त कर रहे हैं।

चौथा, संभावित प्रदर्शन लाभ यह मानने से आते हैं कि सूचकांक में एक लॉगरिदमिक व्यवहार है, और यह नोट करते हुए कि 5log (एन) लॉग (5 एन) से अधिक है, इसलिए 5 छोटे से एक बड़ी अनुक्रमणिका का उपयोग करना बेहतर है। हालांकि, प्रकार के कॉलम के अतिरिक्त इस लाभ को कम करने जा रहा है। मुझे सच में यकीन नहीं है कि इसका विश्लेषण कैसे किया जाए, अगर यह पूरी तरह खत्म हो जाए, या इसे कम करें।

पांचवां, ऐसा लगता है कि कम से कम कुछ प्रश्नों के लिए, आप उस विशाल तालिका की कई प्रतियों में शामिल होने जा रहे हैं, जो वास्तव में ऐसा लगता है कि यह एक हत्यारा होने वाला है।

मुझे यह देखने में दिलचस्पी होगी कि आपको क्या परिणाम मिलते हैं, लेकिन यदि कोई प्रदर्शन लाभ होता है तो मुझे आश्चर्य होगा।

Answer 3

इसे अबास्ट्रक्शन और टेबल विरासत के साथ हल किया जा सकता है।

एक व्यक्तिगत ग्राहक, संगठन ग्राहक, सेवा प्रदाता सभी दल हैं, जो भूमिकाएं निभाते हैं।

एक ईमेल पता, टेलीफोन नंबर, वेब पता, और शारीरिक पता सभी पते हैं।