HTTP सत्र या डेटाबेस दृष्टिकोण


16

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

  1. उपयोगकर्ता लॉग इन नहीं है और कार्ट में उत्पाद जोड़ रहा है (अनाम उपयोगकर्ता)
  2. उपयोगकर्ता लॉग इन है और कार्ट में उत्पाद जोड़ रहा है।

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

लेकिन फिर भी हमें इस उपयोगकर्ता के लिए एक शॉपिंग-कार्ट बनाने की आवश्यकता है, ताकि शॉपिंग-कार्ट बनाने और सहेजने के लिए मेरे पास दो विकल्प हों।

  1. जब उपयोगकर्ता एक उत्पाद जोड़ रहा है, तो डेटाबेस में एक कार्ट बनाएं और इस कार्ट को इस उपयोगकर्ता के साथ जोड़ दें, पल भर में उसने इस कार्ट को उपयोगकर्ता में लॉग इन करने के लिए स्थानांतरित कर दिया।
  2. कार्ट बनाएँ, इसमें उत्पाद जोड़ें और इसे सत्र में सहेजें, जब उपयोगकर्ता डेटाबेस में कार्ट बनाएँ और उपयोगकर्ता के साथ इस कार्ट के साथ लॉग इन करें।

मुझे पता है कि दोनों डेटाबेस संचालित कार्ट सिस्टम के साथ-साथ सत्र आधारित सकारात्मक पहलुओं के साथ-साथ सकारात्मक भी हो सकते हैं, लेकिन यह निश्चित नहीं है कि निम्नलिखित बिंदुओं को ध्यान में रखते हुए सबसे अच्छा तरीका कौन सा हो सकता है।

  1. अनुमापकता
  2. लचीलापन
  3. तानाना
  4. आवेदन गति का ध्यान रखना चाहिए

रास्ता तय करने के लिए इस पहलू पर इनपुट की तलाश है।


2
क्यों? मैं कई सौ ई-कॉमर्स वेबसाइट चलाता हूं और हम सब कुछ कुकीज़ या लोकलस्टोरेज (एचटीएमएल 5) में स्टोर करते हैं। इसके अलावा, सत्र स्मृति का उपयोग करते हैं। जब हम खाता लॉगिन करते हैं तो हम एक टाइमस्टैम्प के साथ एक एन्क्रिप्टेड कुकी का उपयोग करते हैं। हमें एक सत्र की आवश्यकता नहीं है क्योंकि जब कोई पृष्ठ लोड होता है, तो हम एक लोड के बाद सेशनस्टोरेज को संग्रहीत करने और उपयोग करने के लिए एचटीएमएल 5 तकनीकों का उपयोग करते हैं। यह IE8 + संगत मानक वेब तकनीक है।
जेसन सेब्रिंग

@LuiggiMendoza ठीक है क्यों नहीं।
जेसन सेब्रिंग

@ zipstory.com: मैं भी HTML5 आधारित समाधान के बारे में एक नज़र रखना चाहूंगा, लेकिन फिर भी इसके कुछ ब्राउज़र द्वारा समर्थित नहीं होने के कारण, मुझे थोड़ा संदेह है
उमेश अवस्थी

@UmeshAwasthi मुझे लगता है कि मेरे ग्राहक निचले ब्राउज़रों पर बहुत कम मुट्ठी भर लोगों की परवाह नहीं करते हैं लेकिन जाहिर है कि यह एक बुरा तरीका है अगर आपके वेब ट्रैफ़िक में इसका अलग मामला है। मुझे पता है कि अभी भी दुनिया में बहुत सारे IE7 और कभी-कभी IE6 पर XP का उपयोग किया जाता है, लेकिन मेरे कुछ ग्राहक उत्पाद स्टोर में पाए जाते हैं जैसे नॉर्डस्ट्रॉम और मैसी इत्यादि।
जेसन सेब्रिंग

@ zipstory.com: मैं एक ईकामर्स एप्लिकेशन के साथ काम कर रहा हूं जहां क्लाइंट IE6 के लिए भी समर्थन चाहता है, अब आप इसे क्या कहेंगे :)
उमेश अवस्थी

जवाबों:


9

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

डेटाबेस में शॉपिंग कार्ट को स्टोर करें। भंडारण सस्ता है, और हर बार कार्ट के लिए क्वेरी करने के लिए यह एक समस्या-निष्पादन-वार नहीं होना चाहिए।


जब मुझे कार्ट डिटेल पेज दिखाने की आवश्यकता हो तो क्या होगा? क्या हमें सत्र से डेटा संग्रहीत करना चाहिए या डेटाबेस हिट के लिए जाना चाहिए?
उमेश अवस्थी

यदि आप डेटाबेस में कार्ट विवरण संग्रहीत करते हैं, तो हाँ, आपको डेटाबेस को हिट करने की आवश्यकता होगी।
जैकब गाडे

7

दोनों तरीकों के फायदे और नुकसान हैं, लेकिन जिस तरह से मैं इसे देखता हूं, डेटाबेस स्टोरेज के दो बहुत बड़े फायदे हैं।

  1. रिपोर्ट कर रहा है। यदि डेटा सत्र में है, तो आप परित्यक्त कार्ट, रूपांतरण दर आदि की रिपोर्ट नहीं कर सकते।
  2. सत्र समय समाप्त। यदि मैं रात का खाना खाने चला गया और सत्र समाप्त होने के कारण मेरी गाड़ी खाली हो गई तो मैं वापस आ गया तो मैं नाराज हो जाऊंगा। मुझे लगता है कि रिटेलर ऐसा नहीं चाहेगा। हम उपयोगकर्ता को खरीदने की ओर आकर्षित करना चाहते हैं, न कि छोड़ने और छोड़ने की ओर।

6

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

इसके बजाय, हम किसी भी उपयोगकर्ता जानकारी को बार-बार खींचने के लिए HTML5 sessionStorage का उपयोग करते हैं, लेकिन बैंडविड्थ बढ़ाने के लिए हर बार एक कुकी राउटरिप की आवश्यकता के बिना। यह IE8 + है और अन्य सभी आधुनिक ब्राउज़र और मोबाइल डिवाइस इस तकनीक के अनुकूल हैं। लेकिन आप आसानी से एक कुकी में कार्ट को एक कमबैक के रूप में स्टोर कर सकते हैं क्योंकि यह वही है जो हमने पहले किया था। यहाँ एक अच्छी कुकी-कार्ट है: http://simplecartjs.org/

जब उपयोगकर्ता साइन इन या लॉगिन करते हैं, तो हम एक बेक्ड स्टैम्प के साथ एन्क्रिप्टेड कुकी का उपयोग करते हैं।

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


4

आप मान रहे हैं कि सत्र भंडारण और डेटाबेस संग्रहण अनन्य हैं। वे नहीं कर रहे हैं लेकिन चलो मान लेते हैं कि वे हैं।

सत्र संग्रहण का लाभ तीन गुना है:

  1. डेटाबेस में डेटा को स्पष्ट रूप से सम्मिलित करने की आवश्यकता नहीं है। आप बस एक सत्र चर सेट और आप कर रहे हैं। कार्यात्मक रूप से सरल और कम-जोखिम।
  2. उपयोगकर्ता की यात्रा और शॉपिंग कार्ट के जीवन चक्र को प्रबंधित करने की आवश्यकता नहीं है क्योंकि कंटेनर / फ्रेमवर्क आपके लिए ऐसा करते हैं
  3. आमतौर पर पुराने निष्क्रिय सत्रों का ऑटो-सफाई आपके लिए किया जाता है।

सत्र भंडारण के नुकसान:

  1. सत्र आत्मीयता, जब तक आप प्रतिकृति की जांच नहीं करते
  2. कोई विफलता नहीं, जब तक आप डिस्क पर सत्र राज्य की प्रतिकृति या मैनुअल दृढ़ता की जांच नहीं करते, जो जटिल हो सकती है।
  3. सभी सत्रों को स्मृति में संग्रहीत किया जाना चाहिए। यदि आप प्रतिकृति नियुक्त करते हैं तो यह प्रवर्धित है।

डेटाबेस संग्रहण के लाभ:

  1. सत्र आत्मीयता या राज्य प्रतिकृति के बारे में चिंता करने की आवश्यकता नहीं है। आप सभी अनुरोधों को राउंड-रॉबिन कर सकते हैं।
  2. आवेदन में कम स्मृति उपरि।
  3. यदि आदेश पूरा हो गया है, तो डेटाबेस में सब कुछ वैसे भी समाप्त हो जाता है, इसलिए यह पूरा करना आसान बना सकता है क्योंकि डेटा पहले से मौजूद है।

डेटाबेस संग्रहण के नुकसान:

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

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

डेटाबेस-समर्थित सत्र के लाभ:

  1. सर्वर आत्मीयता के लिए कोई ज़रूरत नहीं है।
  2. ऐप सर्वर मेमोरी पर आसान
  3. निष्क्रिय / परित्यक्त सत्र डेटा आपके लिए साफ़ किया जाता है।
  4. उपयोगकर्ता का जीवनचक्र पहली यात्रा, बार-बार आना, सत्र समाप्त होना यह सब आपके लिए है।
  5. कोड करने के लिए आसान है

डेटाबेस-समर्थित सत्र का नुकसान:

  1. कॉन्फ़िगरेशन - आपको अपने कंटेनर की जांच करने की आवश्यकता है, चाहे वह PHP, जावा ईई (टॉमकैट, जेट्टी, जेबॉस, आदि), नोड.जेएस + एक्सप्रेस.जेएस या व्हाट्सएप इसका समर्थन करते हैं और सही कॉन्फ़िगरेशन की आपूर्ति करते हैं।
  2. जब से आप प्रति अनुरोध 2 डेटाबेस ऑपरेशन जोड़ रहे हैं, तब आपको इसे लोड करने की आवश्यकता हो सकती है।

एक तीसरी संभावना है, जिसे पहले किसी ने छुआ था। आप पूरी तरह से सत्र का उपयोग छोड़ सकते हैं और कुकी या HTML स्थानीय भंडारण में सब कुछ एम्बेड करके क्लाइंट-साइड स्टोरेज का उपयोग कर सकते हैं।

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

मैंने आपके लिए तथ्यों को रेखांकित किया है। उम्मीद है कि यह आपकी स्थिति के लिए सही निर्णय लेने में मदद करता है।


आपने खरीदारी के कार्ट में रखी चीजों की दरों का विश्लेषण करने के लिए ऑर्गनाइज़ेशन के डेटाबेस स्टोरेज का फायदा उठाया।
HLGEM

@HLGEM उत्कृष्ट विचार - मैंने ऐसा कभी नहीं सोचा था!
ब्रैंडन

मैं इस सामान के बारे में सोचता हूं क्योंकि मैं वह हूं जो डेटाबेस में डेटा का विश्लेषण करता हूं। डेटाबेस डिजाइन करते समय, पहले प्रश्नों में से एक होना चाहिए कि हमें इस डेटा की आवश्यकता क्या है और शायद ही कोई इसे पूछता है।
HLGEM

3

आइए आपके द्वारा बताए गए दो उपयोग मामलों पर विचार करें

उपयोगकर्ता लॉग इन नहीं है और कार्ट में उत्पाद जोड़ रहा है (अनाम उपयोगकर्ता)

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

उपयोगकर्ता लॉग इन है और कार्ट में उत्पाद जोड़ रहा है।

इस मामले में, आप इसे ऊपर (पुराने स्कूल ई-कॉमर्स साइटों) की तरह ही संभाल सकते हैं और डेटाबेस में इस जानकारी को जोड़ सकते हैं और इसे उपयोगकर्ता के साथ जोड़ सकते हैं। इसका उपयोग मुख्य रूप से स्टेटफुल (सत्र से सत्र तक सहेजे गए राज्य) जैसे "उत्पाद ब्राउज़िंग इतिहास", "अनुशंसाएँ" आदि के लिए किया जाता है।

सोचने वाली बातें:

  • क्या डेटा को सहेजना आवश्यक है?
  • यदि हाँ, तो उपयोगकर्ता को बेहतर सेवा देने के लिए कौन सा डेटा सहेजा जाना सबसे महत्वपूर्ण है?
  • स्केलेबिलिटी + डेटा स्टोरेज - आप कई उपयोगकर्ताओं को समर्थन देने के लिए अपने डेटाबेस में तेजी से देखने के लिए कार्ट की जानकारी कैसे बचाएंगे?

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

लेकिन अंत में यह एक आवश्यकताओं की परिभाषा समस्या है और आपको अपने व्यवसाय को बताना चाहिए कि आप क्या करने की योजना बनाते हैं और यह सुनिश्चित करते हैं कि कुछ भी बनाने से पहले वे यही उम्मीद करते हैं।
HLGEM

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

@HLGEM: बहुत अच्छी बात! मैंने इस सवाल का जवाब केवल एक अतिथि उपयोगकर्ता बनाम साइट के सदस्य के लिए कार की कार्यक्षमता का समर्थन करने की आवश्यकता पर आधारित है। व्यवसाय की दृष्टि से, एक अलग सांख्यिकी प्रणाली होनी चाहिए जो किसी प्रकार की डेटाबेस प्रणाली पर निर्भर हो जो भूगोल के संदर्भ में उत्पाद, उपयोगकर्ताओं के # संबंधित उत्पादों को खरीदती हो, संबंधित उत्पादों को खरीदती हो, आदि
GeekByte

0

सत्र के लिए जाएं जब उपयोगकर्ता लॉग इन नहीं है। तब भी जब सत्र में कार्ट बनाने के लिए पहले लॉग इन किया गया हो, और इसे डेटाबेस में तभी जारी रखें जब उपयोगकर्ता लॉग आउट करे या सत्र बार आउट हो।

आपको सत्र में बनाई जाने वाली गाड़ियों की संख्या पर एक जांच रखने की आवश्यकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.