"बड़े स्टेडियम" टिकट बेचना


10

मैं स्टेडियम की टिकट बिक्री को लागू करना चाहता हूं।
यह विचार ग्राहक को अपने टिकटों की संख्या (उस पर एक कैपिंग की आवश्यकता हो सकती है, लेकिन यह कोई बड़ा मुद्दा नहीं है चुनने के लिए है। मुझे लगता है कि मैं इसे कार्ट में अधिकतम मात्रा के माध्यम से प्राप्त कर सकता हूं)। उसके बाद ग्राहक को अपनी सीट को सीट के नक्शे से चुनना होगा। उसके बाद चेकआउट प्रक्रिया हमेशा की तरह चलनी चाहिए।
क्या किसी को इसके लिए एक विस्तार पता है? मैंने एक खोज की, लेकिन मुझे अपनी आवश्यकताओं के अनुरूप कोई नहीं मिला। या शायद मेरे Google कौशल में सुधार की आवश्यकता है।
यदि कोई विस्तार नहीं है, तो यह कैसे करना है पर कुछ संकेत महान होंगे।
मेरा विचार अब तक कुछ कस्टम विकल्पों (सेक्टर, पंक्ति, सीट संख्या और शायद अन्य) के साथ 'टिकट' नामक एक उत्पाद बनाना है।
दृश्य पृष्ठ कस्टम बनाया जाएगा, इसलिए कस्टम विकल्प नहीं दिखाए जाएंगे। टिकट का चयन एक पॉपअप या ओवरले में होगा, और चयन के आधार पर मैं कार्ट में जोड़ते समय कस्टम विकल्पों का अनुकरण करूंगा।
सीट का नक्शा एक तालिका में रखा जाएगा ताकि मैं बुक की गई सीटों को चिह्नित कर सकूं। स्टेडियम हमेशा एक ही होता है इसलिए एक नक्शा पर्याप्त होना चाहिए।
इसके बारे में अभी तक यही है। कुछ सीम गायब होना। कोई संकेत महान होगा।
[संपादित करें]
3 विशेषताओं (क्षेत्र, पंक्ति और सीट संख्या, प्रत्येक में उपलब्ध मात्रा 1 में संयोजन के साथ एक विन्यास योग्य उत्पाद बनाने की संभावना है ताकि वे खरीदे जाने के बाद उपलब्ध न हों), लेकिन इसका मतलब होगा 30k + उत्पाद (प्रति) प्रतिस्पर्धा)। मैं वहाँ जाना नहीं चाहता। मैं इसे अंतिम हताश रिसॉर्ट के रूप में रख रहा हूं।। (यह अब एक विकल्प नहीं है क्योंकि इसके परिणामस्वरूप ह्युज्यूग प्रदर्शन मुद्दा होगा)

जवाबों:


10

मैंने ऐसा कुछ किया है, और यह एक विरोधाभासी उदाहरण है और यह देखने के लिए सरल है कि क्या आप भी इसे एक व्यवहार्य समाधान मानेंगे:

यह एक सुडोकू ग्रिड को परिभाषित करने के समान है लेकिन यह है कि सुडोकु ग्रिड के खुले क्षेत्र खुली सीटें हैं:

$section1 = <<<SECTION

A,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,
B,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-
C,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-
D,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-
E,-,-,-,-,-,-,-,-,-,-,-,-

SECTION;

वह सीट चार्ट (सुडोकु ग्रिड) प्रति-उत्पाद के आधार पर संग्रहीत किया जाता है। हर घटना एक नया उत्पाद है। ग्रिड को अपडेट किया जाता है जब कोई व्यक्ति गाड़ी में जोड़ता है (या व्यावसायिक नियमों के आधार पर खरीद करता है):

$section1 = <<<SECTION

A,-,-,x,-,-,-,-,-,x,-,-,x,x,x,x,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,
B,-,-,-,-,-,-,-,-,-,-,-,-,-,x,-,-,-,-,-,-,-,-,-,-,-,-,-
C,-,-,-,-,-,x,x,x,-,x,-,x,-,-,-,-,-,-,-,-,-
D,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-
E,-,-,-,-,-,x,-,x,-,x,-,x

SECTION;

अपने बैकएंड मॉडल में सीट की उपलब्धता को तोड़ने के लिए यह एक सरल है explode:

$chart = array();

$section = trim(explode('\n', $product->getSeatingChart()));

foreach($section as $row){
    $seats = explode(',',$row);
    $rownum = array_shift($seats);
    $chart[$rownum] = $seats;
}

हम $chartबूलियंस में बदल सकते हैं :

array_walk($chart,function(&$s){
    $s = $s == "-" ? true : false;
});

जांचें कि क्या A14 उपलब्ध है (0 अनुक्रमित, याद रखें):

function checkAvailability($row,$seatnum){

    return $chart[$row][$seatnum-1] == true;

}

उल्टा:

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

टायर भी काम करेंगे, इसलिए आपको मुफ्त में थोक खरीद छूट मिलती है; कस्टम विकल्पों के साथ एक चिंता का विषय हो सकता है।

नकारात्मक पहलू:

सीट आरक्षण आपका सबसे बड़ा सिरदर्द होने वाला है क्योंकि आप वास्तविक वस्तु-सूची नहीं रखते हैं; बस यहीं से यह विधि अलग हो जाती है। व्यावसायिक नियम निर्धारित करेंगे कि आप चेकआउट के दौरान सीटों को कैसे लॉक / होल्ड करते हैं।


1
+1 वाह। अगर कोई कभी "द आर्ट ऑफ़ मैगेंटो प्रोग्रामिंग" लिखता है, तो यह एक उदाहरण के रूप में बेहतर है।
कालेंजर्दन

सबसे पहले मैं यह कहना चाहता हूं कि मैं एक बेवकूफ की तरह महसूस करता हूं। बेशक मूल्य निर्धारण वर्गों पर होना चाहिए। मेरे मन में कीमत हर सीट पर थी। डी 'ओह !. जहां तक ​​डॉनवसाइड है, मुझे कोई नहीं दिखता। मैं एक साधारण तालिका स्तंभ के साथ हर घटना के लिए आरक्षित / खरीदा सीटों पकड़े कर सकते हैं event_id, sector, row, seat, status। स्थिति 'आरक्षित', 'खरीदी', 'उपलब्ध नहीं' हो सकती है। इस तरह से यह आसान हो जाता है कि आपके द्वारा किए जाने से 2 सेकंड पहले किसी को आरक्षित करना आसान है। मैं एक नया उत्पाद प्रकार (ईवेंट टिकट) बनाने की सोच रहा हूं, ताकि मुझे यकीन हो जाए कि उत्पाद सेटअप पर कोई समस्या नहीं है। जानकारी के लिए धन्यवाद
मेरियस

आपके उत्तर मेरे दिमाग में पहेली के टुकड़े डालने के लिए सीवन हैं। मैं अभी भी प्रदर्शन के मुद्दे के बारे में चिंतित हूं, क्योंकि 4-5 दिनों में 30k टिकटों की बिक्री सर्वरों को बहुत तनाव दे सकती है, लेकिन यह एक अलग मुद्दा है। मैं इस विस्तार को समुदाय के लिए उपलब्ध कराने का प्रयास करूँगा, यदि यह हो गया है और यदि मुझे ग्राहक से 'हरी बत्ती' मिल गई है।
मेरियस

30k टिकट - यह नासकार स्टेडियम है? :) मुझे लगता है कि प्रति घटना (घटनाओं के विन्यास हैं) प्रति-खंड एक एकल टिकट उत्पाद होने से आपके कैटलॉग का आकार काफी कम हो जाएगा। छोटी db पदचिह्न तो उम्मीद है कि पूरी तरह से स्मृति में फिट बैठता है ...
philwinkle

1
@philwinkle मैंने आपको एक ई-मेल भेजा है क्योंकि मैं 20 वीं शताब्दी में रहता हूं और ट्विटर अकाउंट नहीं है।
मेरियस

2

मैं मानता हूं कि विन्यास योग्य उत्पाद एक महान विचार नहीं हैं एक सीट वास्तव में केवल एक संकेतक है यदि इसकी उपलब्ध या बेची गई है और यह मैगेंटो उत्पाद की तरह लगता है जो ओवरकिल की तरह लगता है।

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


धन्यवाद। +1। दार्इंलिंक से एक के साथ संयुक्त आपका जवाब कम से कम मुझे सही दिशा में शुरू करना चाहिए।
मेरियस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.