वर्तमान में मेरे पास लेख और टैग नामक दो तालिकाओं वाला डेटाबेस है। लेखों को कई श्रेणियों में रहने की अनुमति देने के लिए मेरे पास कई रिश्ते हैं। क्या प्रदर्शन के संदर्भ में ऐसा डिज़ाइन होना गलती है? या क्या मुझे इन दो तालिकाओं के बीच संबंध हटा देना चाहिए और एक पुल (लेख टैग) के रूप में एक तीसरी तालिका जोड़ना चाहिए?डेटाबेस डिज़ाइन में कई से अधिक रिश्ते
अनेक-से-अनेक संबंध होने के साथ स्वाभाविक कुछ भी गलत नहीं है, तो आप सिर्फ बनाने की आवश्यकता होगी एक Junction Table उस रिश्ते को सुविधाजनक बनाने के लिए (जो क्या यह लग रहा है आप articlesTags साथ की चर्चा करते हुए कर रहे हैं) है।
यदि डेटा की आवश्यकता होती है तो कई से अधिक रिश्ते होने में कोई समस्या नहीं है, लेकिन आप इसे तीसरी तालिका का प्रतिनिधित्व करने के लिए चाहते हैं।
मैं कहूंगा "आपको तीसरी तालिका की आवश्यकता होगी।" – Dave
एक संबंध मॉडल में कई से अधिक रिश्ते मौजूद हैं, यह केवल दिमाग का एक अमूर्त है। जब आप इसे लागू करेंगे वहाँ एक articles_to_tags तालिका तुम कहाँ होगा होगा:
fk_article (पूर्णांक) fk_tag (पूर्णांक)
कई का प्रयोग करने में कोई समस्या नहीं है कई रिश्तों के लिए। यह अक्सर आवश्यक है।
और हां, तीसरी तालिका का उपयोग किए बिना कई संबंधों को बनाना संभव नहीं है।
आप एक वैचारिक डेटाबेस डिज़ाइन (एन: एन रिश्ते) और इसका भौतिक अहसास के बीच अंतर देख रहे हैं। कोई फर्क नहीं पड़ता कि आप अपने एन: एन रिश्ते को कैसे मॉडल करते हैं, आपको इसे काम करने के लिए उपरोक्त जंक्शन तालिका की आवश्यकता होगी।
असली दुनिया के करीब वास्तविक दुनिया के रिश्ते के मॉडल के साथ कुछ भी गलत नहीं है जैसा कि आप एक सामान्य बयान के रूप में कर सकते हैं। स्पष्टता राजा है।
जब किसी भी सिस्टम में किसी भी प्रदर्शन प्रश्न की बात आती है तो आमतौर पर जवाब "यह निर्भर करता है" तक उबाल जाता है।
यदि आपकी प्रदर्शन समस्या WRITES से संबंधित है तो एक अत्यधिक सामान्य संरचना सर्वोत्तम है और आप उस जंक्शन तालिका को चाहेंगे। आप बहुत कम डेटा लिखना समाप्त कर देंगे और इससे चीजों को काफी हद तक गति मिल सकती है (हालांकि आप आवेषण बनाने से पहले लुकअप करने के द्वारा उस लाभ को जला सकते हैं)। व्यक्तिगत सामान्यीकृत टेबल से पढ़ना भी बहुत तेज़ हो सकता है।
यदि आपकी समस्या विश्लेषणात्मक रीड से संबंधित है तो एक डेनोरमाइज्ड संरचना सर्वोत्तम है। यदि टेबल बड़े होते हैं और सूचकांक फैलते हैं तो जॉइन बहुत अधिक गहन हो सकते हैं। आप बहुत समय पाने के लिए बहुत सारी जगह बलिदान करेंगे।
सामान्य रूप से, आप अपनी स्थिति के विनिर्देशों को देखना चाहते हैं और समाधान पर निर्णय लेने से पहले प्रत्येक दृष्टिकोण के पेशेवरों और विपक्ष का वजन करना चाहते हैं। व्यक्तिगत रूप से, मुझे हमेशा प्रारंभिक चरणों में स्पष्टता और प्रदर्शन के लिए रिफैक्टर पर ध्यान केंद्रित करना बेहतर लगता है यदि मुझे बाद में कोई समस्या आती है।
आपने लेखों के उपयोग के बिना कई सारे रिश्तों को कैसे बनाया? टैग तालिका? – flayto
यदि आपके पास कई से अधिक रिश्ते हैं, तो आपको प्रतिनिधित्व करने के लिए तीसरी तालिका की आवश्यकता है - एक समझदार विकल्प नहीं है। आपका निकटतम दृष्टिकोण प्रत्येक तालिका में एक एसईटी संरचना हो सकता है - यदि आपका डीबीएमएस इसका समर्थन करता है। लेकिन आमतौर पर इस तरह के प्रकार पर अधिक अंतर-तालिका जांच नहीं होती है - अलग तालिका आवश्यक है। –