अलग-अलग फ़ील्ड बनाम अलग तालिका बनाकर

Question

मैं ऐसे प्रोजेक्ट पर काम कर रहा हूं जहां कई प्रकार के उपयोगकर्ता (छात्र और शिक्षक) हैं। वर्तमान में उपयोगकर्ता की जानकारी को स्टोर करने के लिए, दो टेबल का उपयोग किया जाता है। users तालिका उस जानकारी को संग्रहीत करती है जो सभी उपयोगकर्ताओं के समान है। teachers तालिका स्टोर जानकारी संग्रहीत करती है कि केवल शिक्षकों के पास users तालिका से संबंधित एक विदेशी कुंजी है।

users तालिका

• आईडी
• नाम
• ईमेल
• 34 अन्य क्षेत्रों

teachers तालिका

• आईडी
• user_id
• विषय
• 17 अन्य क्षेत्रों

डेटाबेस के बाकी में, वहाँ teachers.id करने के लिए कोई संदर्भ हैं। अन्य सभी टेबल जिन्हें उपयोगकर्ता से संबंधित users.id का उपयोग करने की आवश्यकता है। चूंकि उपयोगकर्ता के पास केवल शिक्षकों की तालिका में एक संबंधित प्रविष्टि होगी, क्या मुझे केवल फ़ील्ड टेबल से उपयोगकर्ताओं को तालिका तालिका में ले जाना चाहिए और उन्हें उन उपयोगकर्ताओं के लिए खाली छोड़ देना चाहिए जो शिक्षक नहीं हैं?

उदा।

users

• आईडी
• नाम
• ईमेल
• विषय
• 51 अन्य क्षेत्रों

एक मेज के लिए यह भी कई क्षेत्रों है? क्या यह प्रदर्शन में बाधा डालेगा?

Answer 1

मुझे लगता है कि इस डिजाइन ठीक है, सबसे कि यह सोचते हैं उस समय के लिए आपको केवल user डेटा की आवश्यकता है, और आपको पता है कि आपको teacher-विशिष्ट फ़ील्ड दिखाने की आवश्यकता है।

इसके अतिरिक्त, आपको केवल JOIN करके केवल शिक्षक ही मिलते हैं, जो आसानी से आ सकते हैं।

कल आपके पास एक और प्रकार का उपयोगकर्ता हो सकता है जो शिक्षक नहीं है, और आप अलगाव से खुश होंगे।

जोड़ने के लिए संपादित: हाँ, यह एक विरासत पैटर्न है, लेकिन चूंकि उसने यह नहीं कहा कि वह किस भाषा का उपयोग कर रहा था, मैं पानी को गड़बड़ नहीं करना चाहता था ...

Answer 2

यह वास्तव में प्रदर्शन को चोट नहीं है, लेकिन अगर आप इसे redisign नहीं होगा अन्य प्रोग्रामर तुम्हें चोट लगी हो सकता है :) (55 मैदान में उतारा टेबल ??)

Answer 3

बाकी डेटाबेस में, शिक्षकों के लिए कोई संदर्भ नहीं हैं। उपयोगकर्ता उपयोगकर्ता से संबंधित सभी अन्य तालिकाओं का उपयोग उपयोगकर्ताओं .id का उपयोग करते हैं।

मैं वर्गों/वर्गों के लिए teacher_id से संबंधित उम्मीद करेंगे ...

के बाद से एक उपयोगकर्ता केवल शिक्षकों तालिका में एक इसी प्रविष्टि नहीं होगी, मैं सिर्फ शिक्षकों मेज से खेतों बढ़ना चाहिए उपयोगकर्ताओं की तालिका में और उन्हें उन उपयोगकर्ताओं के लिए खाली छोड़ दें जो शिक्षक नहीं हैं?

क्या आप हाई स्कूल, या माध्यमिक के लिए सिस्टम तैयार कर रहे हैं? कारण मैं पूछता हूं क्योंकि माध्यमिक में, उपयोगकर्ता कई विषयों में एक शिक्षक और छात्र दोनों हो सकता है।

Answer 4

मैं यह ठीक न आपके द्वारा दी गई या किसी और प्रलोभन को succumbs अन्य प्रयोजनों के लिए 'खाली' कॉलम पुन: उपयोग करने लगता होगा।

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

मैंने इसे कई प्रणालियों पर किया है (उदाहरण के लिए, जब लाइब्रेरी बुक लोनिंग होता है, यदि ऋण एक लंबा ऋण है, तो देय तिथि उस तारीख को रखती है जिसकी तारीख वापस बुक की जाती है। लेकिन यदि यह एक छोटा सा ऋण है उस तारीख को उस समय तक रखा जाता है, जिसकी अपेक्षा की जाती है, और किसी को भी शर्त लगाती है जो किसी भी तरह से उसे नहीं जानता)।

Answer 5

यह नहीं एक मेज के लिए भी कई क्षेत्रों (हालांकि किसी भी जानकारी के बिना यह एक तरह का शक प्रतीत होता है) है। और इस चरण में प्रदर्शन के बारे में चिंता करना समयपूर्व है।

आप शायद बहुत कुछ पंक्तियों और डेटा की एक बहुत छोटी राशि के साथ काम कर रहे हैं। आप चिंताओं को होना चाहिए 1) काम पूरा करना 2) इसे सही ढंग से डिजाइन करना 3) प्रदर्शन, उस क्रम में।

यह वास्तव में एक सौदा (इस चरण/पैमाने पर) का बड़ा नहीं है।

Answer 6

मैं सभी फ़ील्ड को एक टेबल में नहीं रखूंगा। शिक्षक अनुपात के लिए छात्र उच्च है, इसलिए 100 शिक्षकों के लिए उन 17 क्षेत्रों में एनयूएलएल के साथ 10000 छात्र हो सकते हैं। आमतौर पर, एक मॉडल इस के करीब दिखेगा:

अपने मामले

मैं, छात्रों के लिए कोई विशिष्ट क्षेत्रों देखते हैं तो आप Student तालिका छोड़ सकते हैं, इसलिए मॉडल इस

कैसा लगेगा

विरासत मॉडलिंग के लिए, Teacher तालिका UserID, User तालिका के रूप में ही है कि नोट; इसके विपरीत आपके उदाहरण के लिए IdTeacher तालिका के लिए और फिर एक अलग user_id है।