हमेशा की तरह - यह निर्भर करता है।
सबसे पहले, एक अधिकतम संख्या में कॉलम हैं जो MySQL कर सकते हैं समर्थन , और आप वास्तव में वहां नहीं पहुंचना चाहते हैं।
दूसरे, यदि आपके पास इंडेक्स के साथ बहुत सारे कॉलम हैं, तो डालने या अपडेट करते समय एक प्रदर्शन प्रभाव पड़ता है (हालांकि मुझे यकीन नहीं है कि यह आधुनिक हार्डवेयर पर मायने रखता है)।
तीसरा, बड़े टेबल अक्सर सभी डेटा के लिए डंपिंग ग्राउंड होते हैं जो मूल इकाई से संबंधित प्रतीत होते हैं; यह तेजी से डिजाइन को अस्पष्ट बनाता है। उदाहरण के लिए, आपके द्वारा प्रस्तुत डिज़ाइन 3 अलग "स्थिति" प्रकार के फ़ील्ड दिखाता है (स्थिति, is_admin, और fb_account_verified) - मुझे संदेह है कि कुछ व्यावसायिक तर्क हैं जो उन्हें एक साथ जोड़ना चाहिए (उदाहरण के लिए एक व्यवस्थापक एक सत्यापित उपयोगकर्ता होना चाहिए), लेकिन आपका डिजाइन इसका समर्थन नहीं करता है।
यह एक समस्या हो सकती है या नहीं भी हो सकती है - यह एक प्रदर्शन से अधिक एक वैचारिक, वास्तुकला/डिजाइन प्रश्न है/क्या यह काम करेगा। हालाँकि, ऐसे मामलों में, आप खाते के बारे में संबंधित जानकारी को दर्शाने के लिए तालिकाएँ बनाने पर विचार कर सकते हैं, भले ही उसका x-to-अनेक संबंध न हो। तो, आप "user_profile", "user_credentials", "user_fb", "user_activity" बना सकते हैं, जो सभी user_id द्वारा लिंक किए गए हैं। यह इसे अधिक साफ-सुथरा बनाता है, और यदि आपको फेसबुक से संबंधित अधिक फ़ील्ड जोड़ना है, तो वे लटकेंगे नहीं तालिका का अंत। हालाँकि, यह आपके डेटाबेस को तेज़ या अधिक स्केलेबल नहीं बनाएगा। जुड़ने की लागत नगण्य होने की संभावना है।
आप जो कुछ भी करते हैं, विकल्प 2 - "शायद ही कभी उपयोग किए जाने वाले फ़ील्ड" को एक टेक्स्ट फ़ील्ड में क्रमबद्ध करना - एक भयानक विचार है। आप डेटा को मान्य नहीं कर सकते (इसलिए तिथियां अमान्य हो सकती हैं, संख्याएं टेक्स्ट हो सकती हैं, नॉट-नल गायब हो सकती हैं), और "कहां" क्लॉज में कोई भी उपयोग बहुत धीमा हो जाता है।
एक लोकप्रिय विकल्प "इकाई/विशेषता/मूल्य" या "कुंजी/मूल्य" स्टोर है। इस समाधान के कुछ लाभ हैं - आप अपने डेटा को एक रिलेशनल डेटाबेस में संग्रहीत कर सकते हैं, भले ही आपका स्कीमा बदल जाए या डिज़ाइन समय पर अज्ञात हो। हालांकि, उनकी कमियां भी हैं:डेटाबेस स्तर (डेटा प्रकार और अशक्तता) पर डेटा को मान्य करना कठिन है, विदेशी कुंजी संबंधों का उपयोग करके अन्य तालिकाओं के लिए सार्थक लिंक बनाना कठिन है, और डेटा को क्वेरी करना बहुत जटिल हो सकता है - सभी को खोजने की कल्पना करें रिकॉर्ड जहां स्थिति 1 है और facebook_id शून्य है और पंजीकरण की तारीख कल से अधिक है।
यह देखते हुए कि आप अपने डेटा की स्कीमा जानते हैं, मैं कहूंगा कि "कुंजी/मान" एक अच्छा विकल्प नहीं है।
