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

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

आइए देखें कि ऑनलाइन स्टोर के डिजाइन पर चर्चा करते समय आपको क्या विचार करना चाहिए।

मान लीजिए आप पायथन / Django में एक ऑनलाइन स्टोर लिखने जा रहे हैं।

א। उत्पाद डेटा भंडारण

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

इस प्रकार, यह आमतौर पर माना जाता है कि माल को मापदंडों का एक गतिशील सेट निर्धारित करने में सक्षम होना चाहिए।

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

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

एक और विकल्प सब कुछ का उपयोग करना है जो कि Django के लिए यथासंभव मानक है। विशेष रूप से, django - eav है । यह सिर्फ समाधान है जो आपको मॉडल में वस्तुओं के लिए फ़ील्ड का एक गतिशील सेट जोड़ने की अनुमति देता है (बेशक, डेटा एक तालिका में संग्रहीत नहीं किया जाता है - डेटाबेस रिलेशनल रहता है)।

इस मामले में, व्यवस्थापक पैनल के साथ एक तैयार एकीकरण है।

लेकिन सब कुछ इतना चिकना नहीं है: सबसे पहले, यह विकल्प प्रदर्शन के मामले में बहुत अच्छा नहीं है (अर्थात, हम तुरंत सिस्टम की स्केलिंग को जटिल करते हैं - इसलिए यह अधिक उपयुक्त है जब उच्च भार की उम्मीद नहीं की जाती है), और दूसरी बात, हो सकता है कि बहुभाषावाद के कार्यान्वयन में अतिरिक्त कठिनाइयाँ।

सामान्य तौर पर, इवान सागरलाव ईएवी के बारे में लिखते हैं:

ईएवी तब होता है जब विशेषताओं का सेट कठोरता से सेट नहीं किया जाता है या बस बहुत बड़ा होता है। डेटाबेस में कई हजार तालिकाओं के होने से, जिनमें से प्रत्येक में एक कॉलम और कई हजार रिकॉर्ड होंगे, जिनमें से एक या दो भरे हुए हैं, बहुत अच्छा नहीं है।

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

क्या इन उद्देश्यों के लिए MongoDB के साथ Django का उपयोग करने के बारे में कोई बात की गई थी? सामान्य तौर पर, हाँ । Alix Axel उपयोगकर्ता के उत्तर में कुछ अच्छे लिंक हैं (उदाहरण के लिए, इस प्रस्तुति के लिए) जो इलेक्ट्रॉनिक कॉमर्स के लिए MongoDB का उपयोग करने की सुविधाओं को प्रकट करता है। हालांकि, Django के लिए विशिष्ट समाधान वहां उपलब्ध नहीं कराए गए हैं।

यहाँ EAV के साथ-साथ hstore का उपयोग करने के बारे में थोड़ा और बताया गया है (यह PostggSQL के लिए मूल्यों के एक गतिशील सेट को संग्रहीत करने का एक विकल्प है):

• softwaremaniacs.org/forum/django/38394
• softwaremaniacs.org/forum/django/51570

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

- ग्रिगोरी फतेयेव के बारे में यहाँ से ।

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

ב। बहुभाषी

बहुभाषी सामग्री के कार्यान्वयन के लिए विभिन्न समाधान हैं - इस मामले में, विशेष रूप से, सामान के लिए निर्धारित मापदंडों की विभिन्न भाषाओं में अनुवाद। हालाँकि, डेटा संग्रहण के लिए आप किस दृष्टिकोण का उपयोग करने जा रहे हैं, इस पर निर्भर करते हुए, ये अनुप्रयोग उपयुक्त नहीं हो सकते हैं (हालाँकि आप उनमें से किसी एक को अनुकूलित करने का प्रयास कर सकते हैं)।

ג। इतिहास संपादित करें

कई मामलों में, प्रत्येक उत्पाद के लिए संपादन का इतिहास क्लाइंट के लिए बहुत उपयोगी हो सकता है (उदाहरण के लिए, कुछ को पुनर्स्थापित करने के लिए यदि वे उस तरह से संपादित नहीं किए गए थे)।

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

उदाहरण के लिए, django - प्रत्यावर्तन django - प्रत्यावर्तन-तुलना (पृष्ठ को नीचे स्क्रॉल करें - स्क्रीनशॉट हैं) का उपयोग करके अलग - अलग प्रदर्शित कर सकते हैं।

वहाँ भी है django - इतिहास - Uilda डेवलपर ildus का काम। यहाँ django की समीक्षा है - प्रत्यावर्तन, django - संशोधन, और django - सरल - इतिहास।

यदि आप एक गैर-संबंधपरक डेटाबेस का उपयोग करते हैं, तो, ज़ाहिर है, थोड़ा अधिक जटिल है। हालाँकि आम तौर पर खेतों का एक गतिशील सेट + अनुवादों का एक गतिशील सेट मानगो का उपयोग करने के पक्ष में बहुत सम्मोहक तर्क हैं, यह मुझे लगता है। अंत में, आखिरकार, यह इस तरह के "एम्बेडेड" डेटा को संग्रहीत करने के लिए मौजूद है (प्लस यह आसानी से समूह मूल्यों के लिए संभव हो जाता है!)। यहां एकमात्र प्रतिवाद संभवत: मौजूदा ईकॉमर्स समाधानों के साथ एकीकरण की संभव कठिनाई है। दूसरी ओर, इसके साथ, किसी भी मामले में कठिनाइयों किसी भी अपेक्षाकृत जटिल परियोजना के विकास में होगी, अब तक उन्हें पूरी तरह से दरकिनार नहीं किया जा सकता है।

ד। उत्पाद श्रेणियाँ

ज्यादातर मामलों में, सामानों को पेड़ श्रेणियों की आवश्यकता होती है: अर्थात, प्रत्येक श्रेणी में न केवल सामान हो सकते हैं, बल्कि घोंसले के शिकार के कई स्तर भी हो सकते हैं (उदाहरण के लिए, ऑडियो → हेडफ़ोन → ओपन)।

वैसे, यहाँ Django में वस्तुओं के ऐसे पदानुक्रम को लागू करने की एक अच्छी चर्चा है (इसके अलावा django - mptt, कुछ और अच्छे सुझाव हैं)।

ה। एपीआई

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

सामुदायिक विकास

आइए देखें कि समय बचाने के लिए क्या उपयोग किया जा सकता है।

तुलना और समीक्षा:

• www.readncode.com/blog/the-state-of-ecommerce-in-django (अप्रैल 2011)
• valentinewebsystems.com/en/blog/ecommerce-comparison (जुलाई 2010, पायथन में सामान्य रूप से समाधान - सिर्फ Django नहीं, komtet से एक अनुवाद है)
• www.djangopackages.com/grids/g/ecommerce (समय-समय पर अद्यतन / संपादित)

इस विषय पर एक ब्लॉग भी है।

अभी भी हैबे पर ऑस्कर के बारे में एक लेख है ।

सामान्य तौर पर, Satchless और LFS सबसे कम डांटते हैं, जिसका अर्थ है कि हम यह मान सकते हैं कि वे सबसे सभ्य हैं। हालांकि, सबसे सभ्य ones सभ्य लोग, सिद्धांत रूप में, दुर्भाग्य से: व्यवहार में, किसी भी मामले में, आप अपने स्वयं के कांटे के साथ समाप्त होने की अधिक संभावना रखते हैं, और आधिकारिक भंडार से अपडेट को मर्ज करना मुश्किल होगा (या शायद बिल्कुल भी आवश्यक नहीं है) फिर आपको यह निगरानी करने की आवश्यकता है कि क्या उनके आवागमन में कोई सुरक्षा पैच हैं जो आपकी शाखा को भी प्रभावित कर सकते हैं)।

और यह सिर्फ इतना होता है कि सामान के लिए गतिशील क्षेत्रों के विचार के बारे में सैचलेस के लेखक बिल्कुल उत्साही नहीं हैं।

सैचलेस में श्रेणियों की वृक्ष संरचना के साथ, सब कुछ क्रम में लगता है। लेकिन यह इस तरह के किसी भी निर्णय के लिए काफी अपेक्षित है, क्योंकि यह बहुत मांग में है।

एलएफएस (लाइटनिंग फास्ट शॉप) के लिए - तब बॉक्स से बाहर पेड़ की श्रेणियां और एक प्रकार का ईएवी (लेकिन बहुभाषीवाद नहीं) है। हालाँकि, इसे इस तरह से लागू किया गया है कि मैं इसे एक बड़े प्रोजेक्ट पर इस्तेमाल करने से सावधान रहूँगा।

वैसे, सैचलेस के निर्माता LFS को पसंद नहीं करते हैं, क्योंकि वे इसे बहुत अधिक मॉड्यूलर नहीं मानते हैं।

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

पाठक के लिए, मुझे लगता है, यह स्पष्ट है: यदि आप अपना स्वयं का समाधान लिखते हैं जिसमें ऊपर वर्णित सभी समस्याओं को तुरंत हल किया जाता है, और फिर इसे इंटरनेट पर डाल दिया जाता है, तो यह सबसे अधिक संभावना है कि जल्दी से व्यापक हो जाएगा।