स्टैक ओवरव्लो जैसी साइट को देखते हुए, क्या यह सबमिट करने के लिए num_comments कॉलम बनाना बेहतर होगा कि सबमिट करने की कितनी टिप्पणियां हैं और फिर टिप्पणी करते समय इसे अपडेट करें या COUNT फ़ंक्शन के साथ पंक्तियों की संख्या से पूछें? ऐसा लगता है कि उत्तरार्द्ध अधिक पठनीय और सुरुचिपूर्ण होगा लेकिन पूर्व अधिक कुशल होगा। एसओ क्या सोचता है?बेहतर डेटाबेस डिज़ाइन कौन सा है?
निश्चित रूप से COUNT का उपयोग करने के लिए। टिप्पणियों की संख्या संग्रह करना एक क्लासिक डी-सामान्यीकरण है जो सिरदर्द पैदा करता है। यह पुनर्प्राप्ति के लिए थोड़ा अधिक कुशल है लेकिन आवेषण को और अधिक महंगा बनाता है: प्रत्येक नई टिप्पणी के लिए न केवल टिप्पणियों की तालिका में एक डालने की आवश्यकता होती है, बल्कि टिप्पणी गिनती वाली पंक्ति पर एक लिखना ताला होता है।
यह denormalisation अधिक अनुकूलन नहीं है और कुछ ट्रिगर्स की आवश्यकता है - शायद ही कभी सिरदर्द! –
@ जोनब्लैक - हाँ, यह एक अनुकूलन है (हालांकि, जैसा कि मैंने अपने जवाब में कहा था, चाहे "अनुकूलन" सार्थक है, इतना स्पष्ट नहीं है)। साथ ही, यह निश्चित रूप से एक denormalization है। विशेष रूप से, 'num_comments' कॉलम तीसरे सामान्य रूप का उल्लंघन करता है क्योंकि यह एक गैर-कुंजी निर्भरता प्रस्तुत करता है - एक मान जो कुंजी पर निर्भर नहीं है, लेकिन इस मामले में उन मानों पर जो अधिकतर पूरी तरह से अलग तालिका से आते हैं। सिरदर्द के रूप में, यह मुद्दा सिर्फ "कुछ ट्रिगर्स" नहीं लिख रहा है, बल्कि डीबी विकसित होने के साथ ही बाकी सब कुछ के साथ ट्रिगर्स को बनाए रखना है। –
पूर्व सामान्य नहीं है लेकिन बेहतर प्रदर्शन करेगा (लिखने से कई और पढ़ता है)।
उत्तरार्द्ध अधिक सामान्यीकृत है, लेकिन अधिक संसाधनों की आवश्यकता होगी और इसलिए कम प्रदर्शनकारी होगा।
जो आवेदन आवश्यकताओं के लिए बेहतर उबलता है।
मैं टिप्पणी रिकॉर्ड गिनने का सुझाव दूंगा। हालांकि दूसरी विधि तेज होगी, यह एक क्लीनर डेटाबेस को उधार देती है। गिनती कॉलम जोड़ना एक प्रकार का डेटा डुप्लिकेशंस होगा जो अतिरिक्त कोड चरण और सम्मिलित करने के लिए जरूरी नहीं है।
यदि आप लाखों टिप्पणियों की उम्मीद कर रहे थे, तो आप गिनती कॉलम दृष्टिकोण चुनना चाहेंगे।
मैं @ ओडेड से सहमत हूं। यह ऐप की आवश्यकताओं पर निर्भर करता है और यह भी कि कैसे सक्रिय साइट है, लेकिन यहां भी मेरे दो सेंट
डिजाइन करने का "सही" तरीका किसी अन्य तालिका का उपयोग करना, इसमें शामिल होना और COUNT है। यह database normalization सिखाता है के साथ संगत है।
सामान्यीकरण के साथ समस्या यह है कि यह स्केल नहीं कर सकता है। बिल्ली को त्वचा के लिए बहुत सारे तरीके हैं, इसलिए यदि आपके पास प्रतिदिन लाखों प्रश्न हैं और उनमें से बहुत से टेबल एक्स शामिल हैं, तो डेटाबेस प्रदर्शन नीचे जा रहा है क्योंकि सर्वर को समवर्ती लेखन, लेनदेन इत्यादि से निपटना होगा।
इस समस्या से निपटने के लिए, एक सामान्य अभ्यास sharding है। शेरिंग का दुष्प्रभाव होता है कि एक तालिका की पंक्तियों को एक ही भौतिक स्थान में संग्रहीत नहीं किया जाता है, और इसका प्राथमिक परिणाम यह है कि आप JOIN नहीं कर सकते हैं; आधे टेबल के विरुद्ध आप JOIN कैसे और सार्थक परिणाम प्राप्त कर सकते हैं? और जाहिर है, तालिका के सभी विभाजनों के खिलाफ JOIN पर प्रयास करना और परिणामों को विलय करना बीमारी से भी बदतर होगा।
तो आप देखते हैं कि न केवल आपके द्वारा जांच किए जाने वाले विकल्प का उपयोग उच्च प्रदर्शन प्राप्त करने के लिए अभ्यास में किया जाता है, बल्कि यह भी कि कट्टरपंथी कदम भी हैं जो इंजीनियरों कर सकते हैं और कर सकते हैं।
बेशक, जब तक कि आप पर प्रदर्शन समस्याएं, शेरर्ड या यहां तक कि डी-सामान्यीकरण भी आपके जीवन को कोई ठोस लाभ के लिए कठिन बना रहा है।
यह num_comments कॉलम को शामिल करने के लिए स्केल कैसे झुकाता है? –
यदि टिप्पणी गणनाओं को दिखाने के लिए एसओ में शामिल होने की आवश्यकता है, तो यह अस्तित्व में नहीं होगा। लेकिन चिंता कीजिए कि क्या होगा जब आपकी साइट प्रति दिन लाखों पेजव्यूज़ों द्वारा प्रभावित की जाती है, आइए बस कहें, समयपूर्व - इसलिए अपनी परियोजनाओं में, 'COUNT' के साथ जाएं। – Jon
समय से पहले अनुकूलन न करें। डेटाबेस को तब तक सामान्य रखें जब तक आपको उन्हें कम करने की आवश्यकता न हो। – Quentin
@ जोन: दिलचस्प ... क्या आप एक लिंक विस्तृत या प्रदान कर सकते हैं? मैं संबंधपरक मॉडल के बाहर पागल हूं, लेकिन हमेशा सीखने के लिए तैयार हूं ... –