क्या मुझे एएसपी.NET

Question

में प्रमाणित उपयोगकर्ताओं को संदर्भित करने के लिए उपयोगकर्ता नाम या उपयोगकर्ता का आईडी उपयोग करना चाहिए, इसलिए मेरी सरल सीखने की वेबसाइट में, मैं एएसपी.NET प्रमाणीकरण प्रणाली में निर्मित का उपयोग करता हूं।

मैं अब उसकी जिप की तरह सामान को बचाने के लिए एक उपयोगकर्ता तालिका द्वारा जोड़ा जा रहा, जन्म तिथि आदि मेरा प्रश्न है:

1. नई तालिका में, कुंजी उपयोगकर्ता नाम (स्ट्रिंग) या उपयोगकर्ता होना चाहिए आईडी वह GUID दिखने वाला नंबर है जिसे वे asp_ tables में उपयोग करते हैं।
2. यदि सबसे अच्छा अभ्यास उस बदसूरत guid का उपयोग करना है, तो क्या किसी को यह पता है कि इसे कैसे प्राप्त किया जाए? ऐसा लगता है कि नाम (System.Web.HttpContext.Current.User.Identity.Name)
3. यदि आप सुझाव देते हैं कि मैं न तो उपयोग करता हूं (गाइड नहीं और न ही उपयोगकर्ता नाम फ़ील्ड ASP.NET प्रमाणीकरण द्वारा प्रदान किया जाता है) तो मैं इसे एएसपी.NET प्रमाणीकरण के साथ कैसे कर सकता हूं? मुझे पसंद है कि एक विकल्प उपयोगकर्ता के ईमेल पते का उपयोग लॉगिन के रूप में करना है, लेकिन मैं एएसपी.NET प्रमाणीकरण प्रणाली को उपयोगकर्ता नाम के बजाय ईमेल पता का उपयोग कैसे करूं? (या वहाँ कोई लेना देना नहीं है, यह सिर्फ है मुझे निर्णय लेने से मैं "पता" उपयोगकर्ता नाम वास्तव में एक ईमेल पता है

कृपया ध्यान दें:?

• मैं कैसे में एक GUID मिल पर नहीं कह रहा हूँ नेट, मैं सिर्फ userID स्तंभ के लिए asp_ tables में GUID के रूप में GUID जिक्र कर रहा हूँ।
• उपयोगकर्ता नाम ASP.NET प्रमाणीकरण में अद्वितीय है।

Answer 1

मैं तालिका में प्राथमिक कुंजी के रूप उपयोगकर्ता नाम का उपयोग करता है, तो उपयोगकर्ता नाम अद्वितीय होने जा रहा है सुझाव है, वहाँ यह करने के लिए कुछ अच्छे कारण हैं:

1. प्राथमिक कुंजी हो जाएगा एक क्लस्टर्ड इंडेक्स और इस प्रकार उनके उपयोगकर्ता नाम के माध्यम से उपयोगकर्ताओं के विवरण की खोज बहुत तेज होगी।
2. यह
3. प्रदर्शित होने से डुप्लिकेट उपयोगकर्ता नाम बंद हो जाएगा आप सूचना के दो अलग-अलग peices (उपयोगकर्ता नाम या GUID)
4. का उपयोग कर यह लेखन कोड ज्यादा है क्योंकि दो टुकड़े देखने के लिए नहीं होने के आसान हो जाएगा के बारे में चिंता करने की जरूरत नहीं जानकारी की।

Answer 2

आप कुछ अद्वितीय ID का उपयोग करना चाहिए, या तो आप का उल्लेख या कुछ अन्य ऑटो जनरेटर एटीड कुंजी हालांकि, यह संख्या उपयोगकर्ता को कभी दिखाई नहीं देनी चाहिए।

इसका एक बड़ा लाभ यह है कि आपका सभी कोड उपयोगकर्ता आईडी पर काम कर सकता है, लेकिन उपयोगकर्ता का नाम वास्तव में उससे जुड़ा हुआ नहीं है। फिर, उपयोगकर्ता अपना नाम बदल सकता है (जिसे मैंने साइटों पर उपयोगी पाया है)। यह विशेष रूप से उपयोगी होता है यदि आप उपयोगकर्ता के लॉगिन के रूप में ईमेल पते का उपयोग करते हैं ... जो उपयोगकर्ताओं के लिए बहुत सुविधाजनक है (फिर उन्हें सामान्य आईडी आईडी एक लोकप्रिय होने पर 20 आईडी याद रखने की आवश्यकता नहीं है)।

Answer 3

मैं माइक स्टोन से सहमत हूं। मैं उस घटना में केवल एक GUID का उपयोग करने का सुझाव दूंगा जिसमें आप बहुत अधिक डेटा ट्रैक कर रहे हैं। अन्यथा, एक साधारण ऑटो incrementing पूर्णांक (आईडी) कॉलम पर्याप्त होगा।

आप GUID की जरूरत है, तो नेट पर्याप्त सुंदर आप एक सरल से एक मिल सकता है वह यह है कि ...

Dim guidProduct As Guid = Guid.NewGuid() 

या

Guid guidProduct = Guid.NewGuid(); 

Answer 4

आप UserID उपयोग करना चाहिए। यह सदस्यता यूज़र की ProviderUserKey संपत्ति है।

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString()); 

Answer 5

मैं उपयोगकर्ता आईडी का उपयोग करूंगा। यदि आप उपयोगकर्ता नाम का उपयोग करना चाहते हैं, तो आप "उपयोगकर्ता नाम बदलें" सुविधा को बहुत महंगा बनाने जा रहे हैं।

Answer 6

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

मुझे यकीन नहीं है कि यह LinqToSql में एक ज्ञात बग है या क्या, लेकिन मुझे वर्तमान परियोजना पर इसके साथ समस्याएं थीं और मुझे कई तालिकाओं पर पीके और एफके को स्वैप करना पड़ा।

Answer 7

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

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

Answer 8

मैं आमतौर पर एक int वृद्धिशील संख्या का उपयोग करता हूं।

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

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

Answer 9

मैं हालांकि उसके कोड में एक छोटे से त्रुटि हो रहा है Palmsey, से सहमत:

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString()); 

होना चाहिए

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString()); 

Answer 10

मैं उपयोग कहेंगे UserID तो उपयोगकर्ता नाम अभी भी बदला जा सकता है प्राथमिक कुंजी को प्रभावित किए बिना। मैं उपयोगकर्ता नाम कॉलम को डुप्लिकेट करने के लिए अद्वितीय होने के लिए भी सेट अप करूंगा।

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

संपादित करें: यह वर्तमान एएसपी.Net सदस्यता तालिकाओं के साथ भी बेहतर होगा क्योंकि वे उपयोगकर्ता आईडी को प्राथमिक कुंजी के रूप में भी उपयोग करते हैं।

Answer 11

मैं अपने कोड में ग्रिड का उपयोग करता हूं और जैसा कि पहले ही उपयोगकर्ता नाम के रूप में एक ईमेल पता का उल्लेख करता है।यह सब के बाद, उपयोगकर्ता के लिए पहले से ही अद्वितीय और यादगार है। शायद ग्रिड (वी। बहस योग्य) भी खिसकाना।

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

Answer 12

यह पुरानी है, लेकिन मैं सिर्फ लोग हैं जो इस में कुछ बातों का ध्यान रखना खोजने के हैं:

1. aspnet सदस्यता डेटाबेस अनुकूलित है जब यह उपयोगकर्ता के रिकॉर्ड तक पहुँचने के लिए आता है। एसक्यूएल सर्वर में क्लस्टर्ड इंडेक्स (इष्टतम) का उपयोग तब किया जाता है जब लोर्डर्डस नाम और एप्लिकेशनिड का उपयोग करने के लिए रिकॉर्ड की खोज की जाती है। यह बहुत समझ में आता है क्योंकि हमारे पास केवल यूजरनेम उपयोगकर्ता नाम है जब उपयोगकर्ता पहले अपने क्रेडेंशियल्स भेजता है।

2. guid userid int से बड़ा सूचकांक आकार देगा लेकिन यह वास्तव में महत्वपूर्ण नहीं है क्योंकि हम अक्सर एक समय में केवल 1 रिकॉर्ड (उपयोगकर्ता) को पुनर्प्राप्त करते हैं और विखंडन के मामले में, आमतौर पर पढ़ने की संख्या बहुत अधिक है उपयोगकर्ता तालिका में लिखने और संपादन की संख्या - लोग बस उस जानकारी को अद्यतन नहीं करते हैं।

3. regsql स्क्रिप्ट जो एस्पेनेट सदस्यता तालिका बनाता है संपादित किया जा सकता है ताकि उपयोगकर्ता आईडी के लिए डिफ़ॉल्ट के रूप में NEWID का उपयोग करने के बजाय, यह NEWSEQUENTIALID() का उपयोग कर सकता है जो बेहतर प्रदर्शन प्रदान करता है (मैंने इसे प्रोफाइल किया है)।

4. प्रोफ़ाइल। कोई "नई शिक्षा वेबसाइट" बनाने वाला व्यक्ति पहिया को फिर से शुरू करने की कोशिश नहीं करना चाहिए। वेबसाइटों में से एक मैंने एस्पनेट सदस्यता तालिकाओं के बॉक्स संस्करण (भयानक प्रोफ़ाइल सिस्टम को छोड़कर) के उपयोग के लिए काम किया है और उपयोगकर्ता तालिका में लगभग 2 मिलियन उपयोगकर्ता रिकॉर्ड हैं। यहां तक ​​कि रिकॉर्ड की इतनी बड़ी संख्या के साथ, चयन अभी भी तेज़ थे क्योंकि, जैसा कि मैंने शुरू करने के लिए कहा था, डेटाबेस इंडेक्स कमर्डसनाम + एप्लिकेशनिड पर फोकस क्लस्टर इंडेक्स पर ध्यान केंद्रित करने के लिए इन रिकॉर्ड्स की तलाश करते हैं और आम तौर पर बोलते हैं, अगर एसक्यूएल क्लस्टर्ड इंडेक्स की तलाश कर रहा है 1 रिकॉर्ड खोजने के लिए, आपको बड़ी संख्या में रिकॉर्ड्स के साथ कोई समस्या नहीं है, बशर्ते कि आप टेबल पर कॉलम न जोड़ें और बहुत अधिक डेटा वापस खींचना शुरू करें।

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