उपयोगकर्ता प्रोफाइल स्टोर करने के लिए कोई तरीका चुनना?

Question

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

निम्नलिखित तालिका विवरण कथन निष्पादन योग्य नहीं हैं, लेकिन इसमें शामिल तालिकाओं के लेआउट का विचार देने के लिए केवल वहां हैं।

CREATE TABLE user(
    id INT UNSIGNED NOT NULL AUTO_INCREMENT, 

    user_email VARCHAR(320), 

    user_joined DATATIME, 
    user_last_seen DATATIME, 

    user_name_first VARCHAR, 
    user_name_last VARCHAR, 

    user_name_alias VARCHAR, 

    user_location_country VARCHAR, 
    user_location_region VARCHAR, 
    user_location_city VARCHAR 

    # ... 
); 

जाहिर है यह सब पर बहुत स्केलेबल नहीं है और मैं कष्टप्रद अतिरिक्त गुणों को जोड़ने:

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

मेरे दूसरा दृष्टिकोण (एक मैं वर्तमान के साथ चारों ओर खेल रहा हूँ) और अधिक स्केलेबल है, लेकिन मैं प्रदर्शन के बारे में थोड़ा चिंतित हूँ:

CREATE TABLE user(
    id INT UNSIGNED NOT NULL AUTO_INCREMENT, 

    user_email VARCHAR(320) 
); 

CREATE TABLE user_profile(
    user_id INT UNSIGNED NOT NULL, 

    visibility ENUM('PRIVATE', 'PUBLIC'), 

    name VARCHAR, 
    value VARCHAR 
); 

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

क्या एक संकर दृष्टिकोण बेहतर होगा कि मैं दोनों तरीकों के फायदे और नुकसान को संतुलित कर सकूं? एसओ किस विधि का उपयोग करता है? क्या इस पर कोई और दृष्टिकोण है कि मैंने सोचा या याद नहीं किया है?

एक्सटेंशन: एक संकर दृष्टिकोण के साथ यह भी user_profile तालिका में उपयोगकर्ता मेज से गुण सम्मिलित करने के लिए अन्य उपयोगकर्ताओं के लिए उनकी दृश्यता को नियंत्रित करने के लाभप्रद होगा या कि संभवतः अतिरिक्त भूमि के ऊपर के रूप में देखा जा सकता है?

Answer 1

हाइब्रिड समाधान एक अच्छा नहीं है। अनिवार्य रूप से आप एक संपत्ति बैग तालिका में अतिरिक्त संपत्ति भंडार कर रहे हैं। यह लंबे समय तक रिपोर्टिंग और जटिल जटिलताओं को करने जा रहा है। साथ ही, वर्चर के रूप में दिनांक, int, दशमलव, ntext, आदि संग्रहीत करना स्केलेबिलिटी के लिए प्रदर्शन का एक स्वीकार्य विनिमय नहीं होने वाला है। आप उस तालिका से संबंध कैसे बनाएंगे, क्या आवश्यकता पैदा होनी चाहिए?

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

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

Answer 2

मैं एक संकर दृष्टिकोण का उपयोग करता हूं। उपयोगकर्ता नाम, ईमेल, lastlogindate आदि जैसे कुछ बुनियादी गुणों को आपकी उपयोगकर्ता तालिका में जोड़ा जाना चाहिए। माध्यमिक महत्व के आइटम कुंजी/मूल्य जोड़े के रूप में जोड़ा जा सकता है।

इस तरह आप अभी भी सबसे आवश्यक जानकारी की खोज कर सकते हैं और स्कीमा परिवर्तनों के बिना प्रोफ़ाइल आइटम जोड़ना जारी रख सकते हैं।

Answer 3

मैं प्रदर्शन और डिजाइन स्केलेबिलिटी के कारणों के लिए भी हाइब्रिड समाधान के साथ जाऊंगा।

मुझे लगता है कि users जैसे टेबल (मुझे टेबल नामों पर बहुवचन पसंद है) को आम तौर पर अन्य ऑब्जेक्ट्स द्वारा किए गए डेटा के मूल सेट में तोड़ने की आवश्यकता होती है, और मूल रूप से केवल उन्हीं डेटा के विस्तारित बिट्स "क्षेत्र", "middleinitial", "shoesize" जैसे spec को एक एक्स्टेंसिबल और कम बार अपडेट किए गए क्षेत्र में स्थानांतरित किया जा सकता है।

Answer 4

अतिरिक्त जानकारी संग्रहीत करने के लिए XML फ़ील्ड क्यों नहीं है जो आवश्यक नहीं है।

इसे कॉन्फ़िगरेशन फ़ाइल में कॉन्फ़िगर किया जा सकता है और आप इसे एक कदम आगे भी ले सकते हैं और कॉन्फ़िगरेशन से यूआई नियंत्रण उत्पन्न कर सकते हैं।