इंटरमीडिएट टेबल के बिना कई से कई - क्या यह संभव है?

Question

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

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

Answer 1

एक "दुर्लभ कई से अधिक" संबंध अभी भी एक एम: एम संबंध है, और इसे सही ढंग से मॉडलिंग किया जाना चाहिए। इसमें दो तालिकाओं को एक साथ जोड़ने वाली इंटरमीडिएट या एसोसिएशन टेबल बनाना शामिल है। आपके प्रश्न थोड़ा अधिक जटिल होंगे लेकिन केवल अतिरिक्त जुड़ाव शामिल होगा। लेकिन आप है कि आप अपने टेबल सही ढंग से :)

रैंडी

मॉडलिंग की संतुष्टि और अपने साथियों की प्रशंसा करनी होगी

Answer 2

सामान्य रूप से, आप मध्यवर्ती तालिका से बचने में सक्षम नहीं होंगे। जो भी आप एक-से-कई मामलों को आसान बनाने के लिए करते हैं, केवल सामान्य एम: एन केस को सही करने के लिए आपको अधिक प्रयास करते हैं।

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

रूपरेखा स्कीमा:

create table t1 (id integer, xref_t2 set(integer), ...other columns...); 
create table t2 (id integer, xref_t1 set(integer), ...other columns...); 

नोट सुनिश्चित करना है कि 'xref_t2' में मूल्यों वास्तव में अभी भी मान्य हैं (या बाधा लागू करने के लिए एक ट्रिगर लिखने के लिए एक रेफेरेंन्शिअल सत्यनिष्ठा बाधा घोषित करने के लिए कोई आसान तरीका है कि वहाँ)।

सामान्य क्रॉस-रेफरेंस (प्रत्येक तालिका में से एक) के लिए गैर-शून्य कॉलम जैसे वैकल्पिक तंत्र और असामान्य एकाधिक क्रॉस-रेफरेंस (फिर से, प्रत्येक तालिका में से एक) के लिए एक निरर्थक कॉलम, फिर भी यहां तक ​​कि अधिक असामान्य स्थिति जहां यह 1: 2 नहीं है लेकिन 1: 3 या 1: 4 रिश्ते है।

ऐसा करने का सबसे अच्छा तरीका एक स्पष्ट एसोसिएशन टेबल के साथ है।

Answer 7

ठीक है, सब मैं मध्यवर्ती मेज के साथ संभावित भूमि के ऊपर के बारे में सोचने के पहले (शायद मैं इसे जिआदा)

मुझे लगता है कि आप करते हैं। इंडेक्सेड जॉइन वे डेटाबेस हैं जो विशेष रूप से अच्छे हैं।

दूसरा वास्तविक दुनिया के अर्थपूर्ण को व्यक्त करने के बारे में है जो आम तौर पर वस्तुओं में से एक से अधिक संबंध होना चाहिए।

वैसे यह सवाल है कि हम बिना किसी ठोस उदाहरण के जवाब दे सकते हैं: सामान्य से-कई संबंधों की प्रकृति 'विशेष मामले' से कई अलग-अलग होती है? जहां कई से कई होते हैं, क्या संबंध विशेष रूप से मैपिंग के एक और बाकी सभी के बीच अलग-अलग हैं? यदि ऐसा है तो अतिरिक्त मैप के लिए एक तालिका में शामिल होने के साथ, एक मैपिंग के लिए एक अलग इन-पंक्ति संदर्भ होना समझ में आ सकता है।

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