उपयोगकर्ता प्रोफ़ाइल बनाम पुरानी शैली उपयोगकर्ता कक्षा/टेबल

Question

में निर्मित ASP.NET मैं ASP.NET में प्रोफ़ाइल सुविधा के उपयोग के आसपास सर्वोत्तम अभ्यास के बारे में मार्गदर्शन की तलाश में हूं।

आप कैसे तय करते हैं कि अंतर्निहित उपयोगकर्ता प्रोफ़ाइल में क्या रखा जाना चाहिए, या यदि आपको अपनी डेटाबेस तालिका बनाना चाहिए और वांछित फ़ील्ड के लिए कॉलम जोड़ना है? उदाहरण के लिए, उपयोगकर्ता के पास ज़िप कोड होता है, क्या मुझे अपनी खुद की तालिका में ज़िप कोड सहेजना चाहिए, या क्या मुझे इसे web.config xml प्रोफ़ाइल में जोड़ना चाहिए और इसे उपयोगकर्ता प्रोफ़ाइल ASP.NET तंत्र के माध्यम से एक्सेस करना चाहिए?

पेशेवरों/विपक्ष मैं अभी इस बारे में सोच सकता हूं कि चूंकि मैं प्रोफ़ाइल को बहुत अच्छी तरह से नहीं जानता (यह मैट्रिक्स का थोड़ा सा है), मैं शायद जो कुछ भी चाहता हूं, मैं कर सकता हूं तालिका मार्ग (उदाहरण के लिए, एसक्यूएल सभी उपयोगकर्ताओं को एक ही ज़िप कोड में वर्तमान उपयोगकर्ता के रूप में प्राप्त करने के लिए)। अगर मैं ASP.NET प्रोफ़ाइल का उपयोग करता हूं तो मुझे नहीं पता कि मैं वही कर सकता हूं या नहीं।

Answer 1

आईवी ने केवल 2 अनुप्रयोगों का निर्माण किया जो प्रोफ़ाइल प्रदाता का उपयोग करते थे। तब से मैं इसका उपयोग करने से दूर रह गया हूं। दोनों ऐप्स के लिए मैंने उपयोगकर्ता के नाम, पता और फोन नंबर जैसे उपयोगकर्ता के बारे में जानकारी संग्रहीत करने के लिए इसका इस्तेमाल किया।

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

मैं इस प्रकार की जानकारी को अपनी तालिका में संग्रहीत करने की अनुशंसा करता हूं।

Answer 2

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

Answer 3

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

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

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

संपादित करें: इसके अलावा, प्रोफाइल, कैश नहीं तो एक प्रोफ़ाइल के लिए हर पहुँच पहले (यह तो है कि अनुरोध के लिए कैश की गई है, लेकिन अगले अनुरोध फिर डेटाबेस से यह मिल जाएगा)

यदि आप डेटाबेस को जाता है कर रहे हैं अपनी खुद की चीज लिखने के बारे में सोच रहे हैं, शायद custom Profile Provider आपको दोनों दुनिया का सर्वश्रेष्ठ प्रदान करता है - निर्बाध एकीकरण, फिर भी कस्टम सामान जो आप करना चाहते हैं।

Answer 4

उपयोगकर्ता प्रोफ़ाइल व्यक्तिगत अनुकूलन (AKA। प्रोफ़ाइल गुण) के लिए एक अच्छा साफ ढांचा है। (उदाहरण के लिए iGoogle) इसकी समस्या यह क्वेरी के लिए डिज़ाइन नहीं की गई है और सार्वजनिक उपयोगकर्ता को डेटा साझा करने के लिए आदर्श नहीं है।(आप अभी भी कम प्रदर्शन के साथ ऐसा करने में सक्षम होंगे)

इसलिए, यदि आप अनुकूलित उपयोगकर्ता अनुभव को बढ़ाना चाहते हैं, तो उपयोगकर्ता प्रोफ़ाइल जाने का एक अच्छा तरीका होगा। अन्यथा, अपनी खुद की कक्षा और तालिका का उपयोग एक बेहतर समाधान होगा।

Answer 5

मुझे लगता है कि पूरक डेटा के लिए इसका उपयोग करना बेहतर है जो उपयोगकर्ता के लिए महत्वपूर्ण नहीं है जो कि सामान्य रूप से महत्वपूर्ण है जब वह उपयोगकर्ता लॉग इन कर रहा हो। ऐसे डेटा को सोचें जो कुछ भी तोड़ नहीं पाएंगे यदि यह सब मिटा दिया गया था।

निश्चित रूप से व्यक्तिगत प्राथमिकता है लेकिन अन्य ने कुछ अन्य महत्वपूर्ण मुद्दों को उठाया है।

यह भी बहुत उपयोगी है कि इसका उपयोग किसी अनधिकृत उपयोगकर्ता के लिए किया जा सकता है जिसका प्रोफाइल अज्ञात कुकी के साथ बनाए रखा जाता है।