MYSQL: उपयोगकर्ता - प्रोफ़ाइल विवरण तालिका सेटअप - सर्वोत्तम अभ्यास

Question

आपकी सामान्य उपयोगकर्ता तालिका "उपयोगकर्ता" (user_id/user_email/user_pwd/etc) के आगे, प्रोफाइल जानकारी स्टोर करने का सबसे अच्छा तरीका क्या है?

एक बस "उपयोगकर्ता"

(user_id/user_email/user_pwd/user_firstname/user_lastname/user_views/etc) 

तरह उपयोगकर्ता तालिका में फ़ील्ड्स जोड़ने या "प्रोफाइल"

(profile_id/user_id/user_firstname/user_lastname/user_views/etc) 

नामक एक और टेबल बना सकते हैं या एक संपत्ति परिभाषाएँ और के साथ एक मेज के लिए जाना होगा चाहेंगे उन मूल्यों को स्टोर करने के लिए एक और टेबल?

मुझे पता है कि अंतिम सबसे लचीला है, क्योंकि आप आसानी से फ़ील्ड जोड़ और निकाल सकते हैं। लेकिन एक बड़ी साइट के लिए (50k उपयोगकर्ता ऊपर) यह तेजी से होगा?

Answer 1

चीजें अपने दृष्टिकोण

में उपयोगकर्ता टेबल उपयोगकर्ता प्रोफ़ाइल भंडारण के साथ विचार करने के लिए

• यह आम तौर पर, प्रोफ़ाइल डेटा पर हो रही है के मामले में सबसे तेजी से दृष्टिकोण होने जा रहा है, हालांकि आप हो सकता है यहां बहुत सारे अनावश्यक डेटा (कॉलम जिनमें उनमें कोई जानकारी नहीं हो सकती है)।
• त्वरित
• व्यर्थ डाटा
• के साथ काम करने/

उपयोगकर्ता प्रोफ़ाइल भंडारण (जैसे PHPMyAdmin के रूप में इंटरफेस के साथ बेशक) को बनाए रखने के अधिक मुश्किल (विशेष रूप से अगर आप केवल कॉलम आप डाटाबेस से जरूरत खींच) उपयोगकर्ताओं के लिए User_Profile तालिका 1-1 रिश्ते में

• अभी भी एक में शामिल होने और आप कुछ डेटा अतिरेक को खत्म कर सकते हैं के साथ काफी जल्दी होना चाहिए अगर उपयोगकर्ता profi जब तक कि एक उपयोगकर्ता में एक भरता लेस नहीं बनाई गई हैं।
• आसान
• कभी तो थोड़ा धीमे में शामिल होने की वजह से (या 2 क्वेरी)

साथ काम करने के तालिकाओं में गुण और मूल्यों के रूप में उपयोगकर्ता प्रोफ़ाइल भंडारण

* यानीटेबल संभव विकल्प स्टोर करने के लिए, टेबल user_id स्टोर करने के लिए, option_id और मूल्य *

• कोई अनावश्यक डेटा संग्रहीत, सभी डेटा प्रासंगिक है
• अधिकांश सामान्यीकृत विधि
• धीमी पुनः प्राप्त करने और अद्यतन डेटा

मेरी धारणा यह है कि अधिकतर वेबसाइट दूसरी विधि में दूसरी विधि और स्टोर प्रोफ़ाइल जानकारी का उपयोग करती हैं, धीमी लेखन प्रदर्शन की कीमत पर अधिक पढ़ने के प्रदर्शन को प्राप्त करने के लिए डेटाबेस (ट्विटर, फेसबुक) को सामान्यीकृत करने के लिए सबसे बड़ी वेबसाइटों के लिए यह आम है।

मुझे लगता है कि एक दूसरी तालिका में प्रोफाइल जानकारी रखने की संभावना है जब आप 50,000 रिकॉर्ड देख रहे हों। इष्टतम प्रदर्शन के लिए आप डेटा को रखना चाहते हैं जो डेटा से भारी रूप से अलग लिखा गया है ताकि यह सुनिश्चित किया जा सके कि कैश प्रभावी ढंग से काम कर सके।

Answer 2

संपत्ति परिभाषाओं के साथ तालिका अच्छी विचार नहीं है। मैं डेटा स्टोर करने के लिए तीन तालिकाओं का उपयोग करने का सुझाव देता हूं:

user(id,login,email,pwd, is_banned, expired, ...) 
-- rarely changed, keep small, extremaly fast search, easy to cache, admin data 
profile(id, user_id, firstname,lastname, hobby,description, motto) 
--data often changed by user,...  
user_stats(id,user_id,last_login,first_login,post_counter, visit_counter, comment_counter) 
--counters are very often updated, dml invalidate cache 

प्रमाणीकरण और प्रमाणीकरण डेटा स्टोर करने का बेहतर तरीका एलडीएपी है।

Answer 3

आपको 3 से अधिक टेबलों की आवश्यकता है। वह कई ईमेल, एकाधिक पते, एकाधिक शैक्षिक इतिहास, कई "रिश्तों की तलाश" इत्यादि जैसे डेटा कैसे स्टोर करेगा। प्रत्येक को अपनी खुद की पंक्ति की आवश्यकता होती है मानते हैं कि कई मूल्य शहर, लिंग वरीयता, स्कूल के नाम इत्यादि जैसे लुकअप होंगे, इसलिए या तो सामान्य करें यह पूरी तरह से या नोएसक्यूएल मार्ग पर जाता है, बीच में लटकने में कोई बात नहीं, आप दोनों दुनिया के सर्वश्रेष्ठ खो देंगे।

आप पंक्तियों को डुप्लिकेट कर सकते हैं लेकिन यह अच्छा नहीं होगा। सोशल नेटवर्क 50,000 उपयोगकर्ताओं के साथ नहीं रहते हैं। या तो आप सफल होंगे और लाखों उपयोगकर्ता होंगे या आप इसे क्रैश और क्रॉस करेंगे क्योंकि इन्हें चलाने के लिए आपको $$$ की आवश्यकता होगी जो केवल तभी आएगा जब आपके पास ठोस उपयोगकर्ता आधार हो। जीवन निवेशकों के लिए केवल 50,000 उपयोगकर्ता निवेश नहीं करेंगे, विज्ञापन राजस्व लागत को कवर नहीं करेगा और आप इसे बंद कर देंगे। तो इसे डिजाइन करें जैसे कि आप अगले दिन से अगले फेसबुक बनना चाहते हैं। बड़ी सोंच रखना!