PHP: $ _SESSION के अंदर 'ऑब्जेक्ट' स्टोर करना

Question

मुझे अभी पता चला है कि मैं वास्तव में $ _SESSION में वस्तुओं को स्टोर कर सकता हूं और मुझे यह काफी अच्छा लगता है क्योंकि जब मैं किसी अन्य पेज पर जाता हूं तो मेरे पास अभी भी मेरी वस्तु होती है। अब इस दृष्टिकोण का उपयोग शुरू करने से पहले मैं यह पता लगाना चाहूंगा कि क्या यह वास्तव में इतना अच्छा विचार है या यदि संभावित नुकसान शामिल हैं।

मुझे पता है कि अगर मेरे पास प्रवेश का एक भी बिंदु था, तो मुझे ऐसा करने की आवश्यकता नहीं होगी, लेकिन मैं अभी तक वहां नहीं हूं इसलिए मेरे पास प्रवेश का एक भी बिंदु नहीं है और मैं वास्तव में अपनी वस्तु रखना चाहूंगा क्योंकि मैं डॉन ' t मेरे राज्य को ऐसे ही खो देना। (अब मैंने यह भी पढ़ा है कि मुझे स्टेटलेस साइटों को प्रोग्राम करना चाहिए लेकिन मैं अभी तक उस अवधारणा को नहीं समझता हूं।)

तो संक्षेप में : क्या सत्र में वस्तुओं को स्टोर करना ठीक है, क्या इसके साथ कोई समस्या है?

---

संपादित करें:

अस्थायी सारांश : अब तक मैं समझता हूं कि ऑब्जेक्ट को फिर से बनाना बेहतर है , भले ही इसमें डेटाबेस को फिर से क्वेरी करना शामिल हो।

आगे के उत्तर शायद उस पहलू पर थोड़ा और विस्तृत कर सकते हैं !

Comments

मैं 2008 में कैसे बेवकूफ था ':-)

— अंक

लेकिन 2014 में 'बेवकूफों की तरह हमें: डी

— मोमिन अल अज़ीज़

बहुत अच्छे सवाल जो आपने

— मार्कस से

तुम मूर्ख नहीं थे! आपने पूछा कि मैं क्या पूछने वाला था और मुझे 10 साल बाद एक ठोस काम करना था!

— टोडरमो

ठीक है, मैंने अनुमान लगाया कि आपने मुझे 2019 में एक बेवकूफ सवाल पूछने से बचा लिया है

— मैक्सवेल

Answer 1

मुझे पता है कि यह विषय पुराना है, लेकिन यह मुद्दा सामने आ रहा है और मेरी संतुष्टि को संबोधित नहीं किया गया है:

चाहे आप $ _SESSION में वस्तुओं को बचाते हैं, या छिपे हुए प्रपत्र फ़ील्ड्स में डेटा के आधार पर पूरे कपड़े को फिर से संगठित करते हैं, या हर बार DB से उन्हें फिर से क्वेरी करते हैं, आप राज्य का उपयोग कर रहे हैं। HTTP स्टेटलेस (अधिक या कम; लेकिन GET बनाम PUT देखें) लेकिन वेब ऐप के साथ कोई भी काम करने के लिए लगभग हर चीज की आवश्यकता होती है कि कहीं न कहीं इसे बनाए रखा जाए। अभिनय के रूप में अगर राज्य को किसी तरह की सैद्धांतिक जीत के लिए नुक्कड़ और सारस में धकेल दिया जाए तो यह गलत है। राज्य है। यदि आप राज्य का उपयोग करते हैं, तो आप स्टेटलेस होने के कारण प्राप्त विभिन्न तकनीकी लाभों को खो देते हैं। यह कुछ नहीं है जब तक आप पहले से नींद खो दिया है कि आप अग्रिम में पता है कि जब तक नींद खोना नहीं है।

मैं विशेष रूप से "डबल व्हम्मी" द्वारा प्राप्त आशीर्वाद से बहुत खुश हूँ, जो हांक गे द्वारा डाला गया है। क्या ओपी एक वितरित और लोड-संतुलित ई-कॉमर्स प्रणाली का निर्माण कर रहा है? मेरा अनुमान है कि नहीं; और मैं आगे बताऊंगा कि उनके $ प्रयोक्ता वर्ग को क्रमबद्ध करते हुए, या जो भी हो, मरम्मत से परे अपने सर्वर को अपंग नहीं करेगा। मेरी सलाह: उन तकनीकों का उपयोग करें जो आपके एप्लिकेशन के लिए समझदार हैं। $ _SESSION में वस्तुएँ ठीक हैं, सामान्य ज्ञान सावधानियों के अधीन हैं। यदि आपका ऐप अचानक ट्रैफ़िक में प्रतिद्वंद्वी प्रतिद्वंदी अमेज़न में बदल जाता है, तो आपको फिर से अनुकूलन करना होगा। यही ज़िन्दगी है।

Comments

जैसा कि मैंने इसके माध्यम से पढ़ा है, मेरे अपने विचारों को शामिल करते हुए अच्छा जवाब। आधुनिक इंटरनेट को राज्य की आवश्यकता है। हालांकि कुछ अनुप्रयोगों को राज्य की जरूरत नहीं है और एक स्टेटलेस तरीके से बनाने के लिए समझ में नहीं आता है, आधुनिक इंटरनेट बहुत सारी प्रणालियों पर निर्भर करता है जो राज्य पर आधारित हैं (AKA: Logins!) बस उन्हें देने के लिए। इंटरनेट के महान देवताओं ने कुकीज़ के रूप में वर्षों तक उस मूल अवधारणा को भी शामिल किया है, और बुनियादी स्तर पर उन्होंने इसे HTML में स्थानीय भंडारण के रूप में जोड़ा है। यह कुछ अनुप्रयोगों में राज्य के अत्यधिक उपयोग से बचने के लिए समझ में आ सकता है , लेकिन कुछ! = सभी!

— रॉनलुग

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

— अंक

बहुत कम जवाब मुझे ज़ोर से हँसाते हैं। यह एक किया। ब्रावो +1

— toddmo

Answer 2

जब तक सत्र_स्टार्ट () कॉल किया जाता है, तब तक ठीक है, वर्ग घोषणा / परिभाषा पहले ही PHP द्वारा सामना कर चुकी है या पहले से ही स्थापित ऑटोलैडर द्वारा पाया जा सकता है। अन्यथा यह सत्र स्टोर से ऑब्जेक्ट को डिसेर्बलाइज़ करने में सक्षम नहीं होगा।

Comments

धन्यवाद! यह मेरे लिए एक बग तय: डी

— मैट एलेन

मैं यह मान रहा हूं कि यदि आपके पास उचित __autoload()कार्य है तो इस समस्या से बचा जा सकता है ।

— लैंगेल

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

— राजेश पॉल

Answer 3

HTTP एक कारण के लिए एक स्टेटलेस प्रोटोकॉल है। HTTP पर सत्र वेल्ड स्थिति। अंगूठे के एक नियम के रूप में, सत्र राज्य का उपयोग करने से बचें।

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

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

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

@ विन्को आप आमतौर पर सर्वर स्टोर की स्थिति के आसपास काम कर सकते हैं जो आपके द्वारा भेजे जा रहे रिस्पॉन्स पर नज़र रखने वाले डेटा को एम्बेड करके और क्लाइंट इसे पुनः सबमिट करते हैं, जैसे, किसी छिपे हुए इनपुट में डेटा को नीचे भेजना। यदि आपको वास्तव में राज्य के सर्वर-साइड ट्रैकिंग की आवश्यकता है, तो यह संभवतः आपके बैकिंग डेटस्टोर में होना चाहिए।

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

Comments

HTTP स्तर पर सत्र की कोई अवधारणा नहीं है; सर्वर क्लाइंट को एक यूनिक आईडी देकर और क्लाइंट को हर अनुरोध पर उसे फिर से सबमिट करने के लिए कहते हैं। तब सर्वर उस आईडी को सेशन ऑब्जेक्ट के बड़े हैशटेबल में एक कुंजी के रूप में उपयोग करता है। जारी रखने के लिए ...

— हांक गे

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

— हांक गे

मुझे आश्चर्य है कि आप किसी भी तरह वेल्डिंग स्टेट के बिना HTTP पर जटिल अनुप्रयोगों को कैसे लागू करेंगे

— Vinko Vrsalovic

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

— मार्क

"विम्मी वन" काश मैं इसे और कम कर पाता। अपनी टाइमिंग जानिए। एक मेमोरी रेफरेंस की लागत 100 नैनो सेकंड या 0.0001 एमएस है। इसलिए मुख्य स्मृति में संग्रहीत हैशटेबल पर एक खोज करने का शाब्दिक समय नहीं लगता है। है O(1)तुम्हें कुछ बताना? @whammy दो: बस यादृच्छिक सर्वर के लिए सभी अनुरोधों को रूट नहीं करते हैं? राउंड रॉबिन करते हैं, और एक ही उपयोगकर्ता से एक ही सर्वर को रूट करते रहते हैं। यह वाह, सुपर स्पष्ट है। आपको अपनी पुस्तकों के साथ-साथ सभी 30+

— अपवोट्स

Answer 4

• जिन वस्तुओं को क्रमबद्ध नहीं किया जा सकता है (या जिनमें अपरिवर्तनीय सदस्य हैं) $ _SESSION से बाहर नहीं निकलेंगे क्योंकि आप उम्मीद करेंगे
• विशाल सत्र सर्वर पर बोझ डालते हैं (हर बार महंगा होने पर राज्य के सीरियल्स और डिसेरराइजिंग मेग्स)

इसके अलावा मैंने कोई समस्या नहीं देखी है।

Answer 5

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

Comments

प्रत्येक अनुरोध पर डेटा के 5x2 तालिका को क्वेरी करने के बीच प्रदर्शन पर कोई टिप्पणी बनाम सत्र में परिणाम का कैशिंग और उसका उपयोग कर रहा है?

— म्यूज़िकलिफ्ट्समे

Answer 6

मेरा सुझाव है कि राज्य का उपयोग न करें जब तक कि आपको इसकी पूरी आवश्यकता न हो। यदि आप सत्र का उपयोग किए बिना वस्तु का पुनर्निर्माण कर सकते हैं। आपके वेबपेज में स्टेट्स होने से एप्लिकेशन को बनाने में अधिक जटिल हो जाता है, हर अनुरोध के लिए आपको यह देखना होगा कि उपयोगकर्ता किस स्थिति में है। ऐसे समय में जहां आप सत्र का उपयोग करने से बच नहीं सकते हैं (उदाहरण: उपयोगकर्ता को अपने सत्र के दौरान लॉगिन रखना होगा। webapplication)। अंतिम मैं आपके सत्र ऑब्जेक्ट को जितना संभव हो उतना छोटा रखने का सुझाव दूंगा क्योंकि यह बड़ी वस्तुओं को क्रमबद्ध और गैर-व्यवस्थित करने के लिए प्रदर्शन को प्रभावित करता है।

Comments

तो, क्या सभी डेटाबेस प्रश्नों को फिर से करने सहित वस्तु का पुनर्निर्माण करना बेहतर है? क्योंकि ऐसा करने के लिए मेरा एक विचार यह था कि मुझे db को फिर से उसी सामान के लिए क्वेरी करने की आवश्यकता नहीं है।

— मार्कस

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

— जॉनी

धन्यवाद, मुझे वास्तव में लगता है कि यह नहीं है। मुझे बस फिर से सवाल करना चाहिए।

— मार्कस

Answer 7

आपको याद रखना होगा कि संसाधन प्रकार (जैसे db कनेक्शन या फ़ाइल पॉइंटर्स) अभ्यस्त पृष्ठ लोड के बीच बने रहते हैं, और आपको इनको फिर से बनाने की आवश्यकता होगी।

सत्र के आकार पर भी विचार करें, यह कैसे संग्रहीत किया जाता है, इसके आधार पर, आपके पास आकार प्रतिबंध या विलंबता समस्याएँ हो सकती हैं।

Answer 8

सॉफ़्टवेयर पुस्तकालयों को अपग्रेड करते समय मैं भी लाऊंगा - हमने अपने सॉफ़्टवेयर को अपग्रेड किया और पुराने संस्करण में V1 सॉफ़्टवेयर के क्लास नामों के साथ सत्र में ऑब्जेक्ट थे, नया सॉफ़्टवेयर क्रैश हो रहा था जब उसने सत्र में ऑब्जेक्ट्स का निर्माण करने की कोशिश की थी - V2 के रूप में सॉफ्टवेयर अब उन्हीं वर्गों का उपयोग नहीं करता है, यह उन्हें नहीं मिल सका। हमें सत्र ऑब्जेक्ट्स का पता लगाने के लिए कुछ फिक्स कोड डालने थे, यदि पाया गया तो सत्र को हटा दें, पृष्ठ को फिर से लोड करें। शुरू में मन में सबसे बड़ा दर्द जब आप इस बग को फिर से बना रहे थे, जब यह पहली बार रिपोर्ट किया गया था (सभी बहुत परिचित हैं, "ठीक है, यह मेरे लिए काम करता है" :) क्योंकि यह केवल उन लोगों को प्रभावित करता है जो हाल ही में पुराने और नए सिस्टम से बाहर हैं - हालांकि, अच्छा नौकरी हमें लॉन्च से पहले मिल गई क्योंकि हमारे सभी उपयोगकर्ता निश्चित रूप से अपने सत्रों में पुराने सत्र चर रहे होंगे और संभवतः सभी के लिए दुर्घटनाग्रस्त हो गए होंगे,

वैसे भी, जैसा कि आप अपने संशोधन में सुझाव देते हैं, मुझे भी लगता है कि वस्तु को फिर से बनाना बेहतर है। तो हो सकता है कि सिर्फ आईडी स्टोर करना और फिर डेटाबेस से ऑब्जेक्ट को खींचने वाले प्रत्येक अनुरोध पर, बेहतर / सुरक्षित है।