तालिका में उपयोगकर्ता सेटिंग्स को संग्रहीत करना - कैसे?

मेरे पास उपयोगकर्ता के बारे में 200 सेटिंग्स हैं, इनमें ऑब्जेक्ट्स पर उपयोगकर्ता गतिविधियों से नोटिस सेटिंग्स और ट्रैकिंग सेटिंग्स शामिल हैं। समस्या यह है कि इसे डीबी में कैसे स्टोर किया जाए? क्या प्रत्येक सेटिंग एक पंक्ति या स्तंभ होना चाहिए? यदि कॉलमम तालिका में 200 कॉलम होंगे। यदि पंक्ति के बारे में 3 कॉलम हैं लेकिन उपयोगकर्ता पंक्ति प्रति 200 पंक्तियां भी 10 मिलियन उपयोगकर्ता = अच्छा नहीं है।तालिका में उपयोगकर्ता सेटिंग्स को संग्रहीत करना - कैसे?

तो मैं इन सभी सेटिंग्स को और कैसे स्टोर कर सकता हूं? नोट: ये सेटिंग्स टेक्स्ट प्रविष्टि और एफके लुकअप का मिश्रण अन्य तालिकाओं में हैं।

धन्यवाद।

स्रोत

2010-12-27 Mdillion

यदि आपको कुछ फ़ील्ड पर खोजने की आवश्यकता नहीं है, तो आप उन्हें एक टेक्स्ट फ़ील्ड में क्रमबद्ध और स्टोर कर सकते हैं। मेरे लिए, प्रति फ़ील्ड एक कॉलम बनाना ठीक है। खोज/चयन को बेहतर बनाने के लिए, आप उन्हें कई सारणी में विभाजित कर सकते हैं जैसे user_profile, user_inteface_settings, उपयोगकर्ता _... (टेबल जिन्हें तुरंत इस्तेमाल किया जा सकता है)। - एक सामान्य तालिका बनाना जिसमें सेटिंग्स शामिल हैं: यदि आपके पास बहुत से वैकल्पिक फ़ील्ड हैं और 200 * 10 000 000 = 2 000 000 000 पंक्तियों की तालिका के परिणामस्वरूप एक प्रति पंक्ति (uid, फ़ील्ड, मान) उपयोगी है। –

एमडीआईएलियन - बस आपको याद दिलाने के लिए, आपको उस उत्तर को 'स्वीकार' करना चाहिए जिसने आपको सबसे ज्यादा मदद की। –

मेरी समस्या अभी भी हल नहीं है। यहां बहुत सारी सेटिंग्स हैं और यहां वर्णित दोनों तरीके ठीक से काम नहीं कर रहे हैं। तो मैं कुछ अन्य विकल्पों की खोज कर रहा हूं और एक बार मुझे कुछ मिल जाए तो मैं निकटतम जवाब स्वीकार करूंगा। – Mdillion

आपके पास ट्रैक करने के लिए 200 सेटिंग्स हैं जो एक लचीला डेटाबेस स्कीमा सुझाती है।

उपयोगकर्ता: गुण एक उपयोगकर्ता की संभावना हमेशा होगा कि, इस तरह के उपयोगकर्ता नाम और पासवर्ड के रूप में के लिए प्रति उपयोगकर्ता पंक्ति के साथ तालिका में इस तरह के रूप में मैं एक संकर दृष्टिकोण सुझाव देना चाहेंगे। यह तालिका विदेशी कुंजी भी रख सकती है, लेकिन यह एक उदारवादी है और यह भी निर्भर करता है कि रिश्ते शून्य-से-1 या शून्य से बहुत अधिक है। जहां बाद वाले को एक अलग टेबल की आवश्यकता होती है।
विशेषताएं: दो विकल्प
1. सारणी सुविधा प्रति पंक्ति के साथ, प्रभावी रूप से एक hashtable, userId, नाम और मान कॉलम के साथ। यह विदेशी संबंधों के लिए भी एक स्थान हो सकता है, लेकिन आप इस सेटअप में डेटा अखंडता को लागू करने में सक्षम नहीं होंगे।
2. एक्सएमएल, लेकिन केवल एक डेटाबेस के साथ जिसमें ऐसी विशेषताएं हैं जो आपको डेटा से पूछताछ करने की अनुमति देती हैं या केवल उस डेटा के लिए जो आपको क्वेरी करने की आवश्यकता नहीं है, लेकिन केवल आपके एप्लिकेशन सर्वर पर काम करती है।

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

स्रोत

2010-12-27 10:18:58 orangepips

क्या है यदि समय 10 लाख पंक्तियां कहता है और सेटिंग पृष्ठ लोड करने के लिए उपयोगकर्ता के लिए 200 सेटिंग्स ढूंढने की आवश्यकता है तो समय पढ़ें? क्या उपयोगकर्ता पृष्ठ को तत्काल देखेगा या उपयोगकर्ता को देखने और लोड करने में एक मिनट की तरह लगेगा? – Mdillion

सही सूचकांक के साथ, पढ़ने का समय अच्छा होना चाहिए। यह ध्यान दिया गया है कि, जब भी किसी अनुमति की जांच की आवश्यकता होती है, तो मैं डेटाबेस ट्रिप को दोहराने के बजाय उपयोगकर्ता के सत्र के हिस्से के रूप में लॉगिन पर जानकारी लोड करने का सुझाव दूंगा। – orangepips

मुझे लगता है कि संग्रहीत प्रोसेस लिखने में कठिनाई के कारण 200 कॉलम निश्चित रूप से अच्छा विचार नहीं है, मैन्युअल रूप से डेटा देख रहा है या बाद में और सेटिंग्स में विस्तार कर रहा है।

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

स्रोत

2010-12-27 10:06:16

क्या आप एफके को एक्सएमएल में डाल सकते हैं? – Mdillion

मुझे पूरा विवरण नहीं है, लेकिन यह किया जा सकता है। इसे पढ़ें: http://www.stylusstudio.com/xsllist/200205/post70200.html http://msdn.microsoft.com/en-us/library/ms345117(v=sql.90).aspx –

डेटा को सीरियलाइज करना लगभग हमेशा एक बुरा विचार साबित होता है, क्योंकि ऐसा करने में आप डीबीएमएस को अपंग करते हैं। एक कुशल डीबीएमएस बनाने में गए सभी आदमी साल बिट्स की सीरियलाइज्ड बाल्टी पर बर्बाद हो जाएंगे।

आप आवेदन तर्क प्रत्येक सेटिंग के खिलाफ झुका है, तो मुझे लगता है कि या तो आप के रूप में यह लागू करना चाहिए: सेटिंग तालिका में सेट करने से प्रति

1 स्तंभ। इससे आपके डीबीएमएस की शक्ति का लाभ उठाना आसान हो जाता है, बाधा जांच, रेफरेंसियल अखंडता, आपके मूल्यों के लिए सही डेटा प्रकार, ऑप्टिमाइज़र को बहुत सारी जानकारी। नकारात्मकता यह है कि पंक्ति का आकार बढ़ता है। सेटिंग प्रति

या

1 तालिका (या संबंधित सेटिंग्स के समूह)। इसमें उपर्युक्त सभी लाभ हैं, लेकिन जब आप अधिकतर या सभी सेटिंग्स को एक साथ लाने की आवश्यकता होती है तो प्रदर्शन प्रदर्शन के लिए पंक्तियां पंक्तिबद्ध होती हैं।जब सेटिंग्स वैकल्पिक होती हैं, तो वास्तविक डेटा स्पैस होने पर यह विकल्प काफी छोटा होगा।

इसके अलावा, बहुत से कॉलम अक्सर "गंध" होते हैं, जो बताते हैं कि आपने अपना डेटा सही तरीके से सामान्य नहीं किया है, लेकिन ऐसा नहीं होना चाहिए। केवल आप ही अपना डेटा जानते हैं।

स्रोत

2010-12-27 10:47:28 Ronnis

बहुत सारे कॉलम "प्रति उपयोगकर्ता गतिविधि के गोपनीयता स्तर" के कारण हैं। प्रत्येक उपयोगकर्ता गतिविधि में उपयोगकर्ता ने गोपनीयता स्तर को एक डिफ़ॉल्ट सिस्टम परिभाषित गोपनीयता स्तर परिभाषित किया है। सिस्टम सेटिंग के लिए यह ठीक है लेकिन उपयोगकर्ता के निपटान हाथ से बाहर निकलते हैं जब हमारे पास प्रत्येक की अपनी सेटिंग के साथ 200 गतिविधियां होती हैं। – Mdillion

तालिका में उपयोगकर्ता सेटिंग्स को संग्रहीत करना - कैसे?

उत्तर

संबंधित मुद्दे