संबंधपरक डेटाबेस डिजाइन एकाधिक उपयोगकर्ता प्रकार

Question

मैं प्रयोक्ताओं की एक 4 प्रकार है और प्रत्येक विशिष्ट डेटा है, लेकिन वे भी commun डेटा साझा, username, password .. की तरह

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

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

क्या कोई अन्य विकल्प हैं? ऐसे मामले में अच्छा अभ्यास क्या होगा?

बहुत धन्यवाद

Answer 1

आपका केस कक्षा/उप-वर्ग के उदाहरण की तरह दिखता है।

उप-वर्गों से निपटने के लिए SQL तालिकाओं को डिज़ाइन करने के दो क्लासिक तरीके हैं। प्रत्येक के पास फायदे और नुकसान होते हैं।

एक तरफ "सिंगल टेबल विरासत" कहा जाता है। इस डिज़ाइन में सभी प्रकार के उपयोगकर्ताओं के लिए केवल एक टेबल है। यदि दिया गया कॉलम किसी दिए गए पंक्ति से संबंधित नहीं है, तो चौराहे को शून्य छोड़ दिया जाता है। उपयोगकर्ता प्रकार को इंगित करने के लिए एक कॉलम जोड़ा जा सकता है।

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

आप इन तीनों डिज़ाइनों को SO में टैग या वेब पर लेखों के रूप में देख सकते हैं।

single-table-inheritance class-table-inheritance shared-primary-key

Answer 2

यह करने के लिए मेरे रास्ते एक मेज आम क्षेत्रों के साथ "व्यक्ति", और एक विदेशी कुंजी "person_id" के साथ उपयोगकर्ता के प्रत्येक प्रकार के लिए एक तालिका बनाने के लिए हो गया होता।

आपके अनुरोध में, आपको एक प्रकार के उपयोगकर्ता के लिए सभी डेटा प्राप्त करने के लिए केवल विदेशी_की के साथ दो तालिकाओं में शामिल होना होगा।

आपके पास कितने प्रकार के उपयोगकर्ता हैं?

Answer 3

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

बेहतर विकल्प है कि किसी भी उपयोगकर्ता प्रकार के बारे में जानकारी संग्रहीत करने के लिए पर्याप्त कॉलम वाले उपयोगकर्ता तालिका रखना है, यह जानकर कि कुछ कॉलम कुछ उपयोगकर्ता प्रकारों के लिए उपयोग नहीं किए जाएंगे। अप्रयुक्त कॉलम रखने की "अक्षमता" निष्पादन गति और क्वेरी सादगी में मुआवजे से अधिक होगी।

यह भी आसानी से विस्तार योग्य है, यदि आपको कोई अन्य उपयोगकर्ता प्रकार मिलता है - टेबल जोड़ने के लिए कॉलम जोड़ने से कहीं अधिक आसान है, और जैसे ही आप अधिक उपयोगकर्ता प्रकार जोड़ते हैं, नए कॉलम की आवश्यकता कम हो जाएगी (वहां बस नहीं हैं ' टी जो उपयोगकर्ता को स्टोर करने की आवश्यकता है उसके बारे में कई अलग-अलग चीजें)