2008-10-10 2 views
7

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

बहुत सी चर्चा के बाद ऐसा लगता है कि हम शायद स्क्रैच से शुरू हो जाएंगे (कम से कम वर्तमान समय को बनाए रखने के दौरान)। हम चीजों की एक जोड़ी के लिए देख रहे:

  1. एक अच्छा जीयूआई सामने अंत के साथ प्रणाली बनाएँ (यह वर्तमान में चूई है और आवेदन के लिए एक रास्ता है कि हम सामने के छोर नया स्वरूप के लिए अनुमति देता में नहीं बनाया गया था ... व्यापार तर्क और गुई के कोई लेयरिंग या अलगाव नहीं ... shudder)।

  2. विभिन्न कार्यक्षमताओं को मॉड्यूलर करने की क्षमता के साथ सिस्टम बनाएं ताकि उत्पाद में सभी सुविधाएं शामिल न हों। यह हमारे मौजूदा ग्राहकों के लिए लागत को कम रखेगा जो बुनियादी कार्यक्षमता और कम कीमत वाले टैग चाहते हैं। घंटी और सीटी उन लोगों के लिए उपलब्ध होगी जो उन्हें चाहेंगे।

  3. किसी भी समय किसी भी हिस्से को जोड़ने या बदलने के लिए उचित डिजाइन पैटर्न का उपयोग करें (यानी डेटाबेस को बदलें या एप्लिकेशन को फिर से लिखने के बिना फ्रंट एंड को बदलें)। यह आज एक समस्या है क्योंकि प्रगति 4 जीएल कोड सीधे डेटाबेस के खिलाफ संकलित है। डेटाबेस में छोटे बदलावों के लिए बहुत सारे कोड recompiling की आवश्यकता है।

हमारी नई प्रणाली लिनक्स आधारित होगी, एक ग्राहक अनुप्रयोग की संभावना एक या अधिक खिड़कियों के बक्से से कार्यक्षमता प्रदान करने की संभावना के साथ होगी।

तो मैं जो खोज रहा हूं वह कोई सुझाव है जिस पर डेटाबेस और/या ढांचे या प्रोग्रामिंग भाषाएं इस प्रकार के उत्पाद के लिए सिफारिश कर सकती हैं। जो भी इस क्षेत्र में अनुभव करता है वह हमें सही दिशा में इंगित करने में सक्षम हो सकता है या यहां तक ​​कि कुछ विचारों से बचने के लिए भी कुछ विचार कर सकते हैं। हमने .NET और SQL Express (हमें एंटरप्राइज़ लेवल डीबी की आवश्यकता नहीं है) पर विचार किया है, लेकिन यह हमें विंडोज़ तक सीमित कर देगा (जहां तक ​​मुझे पता है)। मैंने लिनो पर्यावरण में .NET कोड लिखने के लिए मोनो के बारे में सुना है, लेकिन मुझे अभी तक इसके बारे में बहुत कुछ पता नहीं है। हमने जावा और माइस्क्ल आधारित कार्यान्वयन भी माना है।

संक्षेप में हम निम्न कार्य करने के लिए देख रहे हैं:

  1. रखें लाइसेंस प्रौद्योगिकी हम उत्पाद विकसित करने के लिए प्रयोग करेंगे पर नीचे लागत (Oracle, उफ़ MySQL, अच्छा!।)

  2. एक समाधान प्रदान करें जो आसानी से रखरखाव योग्य और सहायक हो।

  3. एक समाधान जिसमें एक CHUI फ्रंट एंड के माध्यम से "पुराना" हार्डवेयर चलाने में सक्षम घटक है। (हमारे कुछ ग्राहकों के पास 40+ टर्मिनल हैं जो पीसी पर कनवर्ट करने के लिए नकदी का एक टन होगा)।

सुझावों की सराहना की जाएगी।

धन्यवाद

[अद्यतन] मुझे लगता है कि हम वर्तमान में कुल लागत विश्लेषण प्रदर्शन कर रहे हैं पर ध्यान देना चाहिए। यह प्रश्न हमें शामिल करने या विश्लेषण में शामिल होने के लिए कुछ "शिक्षित" विकल्प देने का इरादा है। कोई भी जो क्लाइंट/सर्वर सेटअप के बारे में अनुभव/सुझाव साझा कर सकता है उसकी सराहना की जाएगी (न केवल उन लोगों को जिन्हें बिक्री प्रणाली के बिंदु के साथ अनुभव है ... यह केवल एक बोनस होगा)।

[अद्यतन]

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

उत्तर

1

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

आपको इस पर बहुत अधिक लेगवर्क करने की आवश्यकता है। वेब फ़ोरम से राय प्राप्त करना बहुत अच्छा है, लेकिन हम संभवतः आपके पर्यावरण को और साथ ही साथ नहीं जानते हैं।

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

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

+0

पुन: लिखना अभी तक एक निश्चित चीज़ नहीं है (मेरा मतलब है कि अभी एक वर्तमान कुल लागत विश्लेषण किया जा रहा है, ऐसा लगता है कि हम एक पुनर्लेखन करना चाहते हैं)। हम एक पुनर्लेखन के लिए विकल्पों की जांच कर रहे हैं जो अधिक लागत को सूचित करेंगे। शिक्षित विचार देने के लिए यही सवाल है। –

+0

बीबी ने एक शानदार प्रौद्योगिकी चुनने के बारे में सिर पर नाखून मारा। यह वास्तव में बेकार है जब SupaDupaDB में आपका एक विशेषज्ञ छोड़ देता है और आप चीन में सभी पैसे के लिए एक और नहीं पा सकते हैं। –

2

जावा भाषा के लिए (या स्काला यदि आप "किनारे खून बह रहा है" करना चाहते हैं, आप इसे कैसे और क्या आपके डेवलपर्स रहे हैं जैसे कि यह बेहतर हो सकता है, लेकिन यह भी बदतर समर्थन करने की योजना के आधार पर)

डेटाबेस के लिए एच 2 के लिए जीयूआई

कारण

घुमाओ: नि: शुल्क, पोर्टेबल और सुंदर मानक।

अद्यतन: उस भाग को याद किया जहां सिस्टम क्लाइंट-सर्वर सेटअप होना चाहिए। मेरी धारणा यह थी कि डेटाबेस और क्लाइंट को उसी मशीन पर चलाना चाहिए।

+0

कोई भी मौका आप इस बारे में कुछ अंतर्दृष्टि दे सकते हैं कि आप इन्हें क्यों सुझाव दे रहे हैं? क्या किसी और चीज पर इनका उपयोग करने के लिए कोई विशिष्ट फायदे हैं? धन्यवाद –

+0

जावा एक मानक है जैसा यह आता है। और यह पोर्टेबल है, जिसे आपने सुझाव दिया है कि यह होना चाहिए। एच 2 एक एम्बेडेड डेटाबेस है, जो आपके जैसे किसी विशेष एप्लिकेशन में सहायक होना चाहिए। इसके अलावा एच 2 (रचनाकारों के दावे द्वारा) प्रदर्शन और प्रकाश है। निर्भरताओं से बचने के लिए बस स्विंग करें। यह बहुत ही अच्छा है। –

+0

धन्यवाद जॉन। यह वह चीज है जिसे हम ढूंढ रहे हैं। –

1

मेरा सुझाव है कि आप यूआई के लिए ब्राउज़र का उपयोग करें।

अपने एप्लिकेशन को वेब एप्लिकेशन के रूप में व्यवस्थित करें।

बैक-एंड के लिए कई विकल्प हैं। आप जावा + MySQL का उपयोग कर सकते हैं। जावा बैकएंड आपको विंडोज/लिनक्स बहस से बचाएगा क्योंकि यह दोनों प्लेटफार्मों पर चलता है। जावा और MySQL दोनों के लिए आपके पास कोई लाइसेंसिंग लागत नहीं होगी। (संपादित करें: निश्चित रूप से वहाँ दूसरों भाषाओं किया है कि सहित & खिड़कियों पीएचपी, रूबी, अजगर आदि दोनों लिनक्स के लिए रन-समय की एक बहुत हैं)

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

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

+0

मैं वास्तव में नहीं देख सकता कि जीयूआई-लेयर और सिस्टम के बीच HTTP और दोस्तों का उपयोग करने की अतिरिक्त जटिलता कैसे लाभान्वित होगी। प्वाइंट ऑफ सेल्स सिस्टम विकसित करते समय –

+0

ब्राउज़र आधारित यूआई के साथ सावधान रहें। यह आमतौर पर विशेष हार्डवेयर (जैसे थर्मल प्रिंटर, बारकोड स्कैनर इत्यादि) के साथ एकीकृत करता है।) – Snackmoore

1

CHUI क्या है? कैरेक्टर-यूआई, जैसा कि वीटी टर्मिनल में है? या यहां तक ​​कि 3270 शैली?

ऐसा लगता है कि आप एक 3-स्तरीय प्रणाली की जरूरत है - डेटाबेस बैकएंड, एक मध्यम परत है कि बैकएंड व्यापार प्रक्रियाओं के थोक चलाता है, और चूई/जीयूआई/डेटा प्रवेश द्वार के लिए एक सामने के अंत परत ।

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

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

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

1

गोल्डन कोड विकास (www.goldencode.com देखें) एक ऐसी तकनीक है एक संबंधपरक डेटाबेस बैकेंड के साथ एक जावा अनुप्रयोग के लिए प्रगति 4GL (स्कीमा और कोड ... पूरा आवेदन) के रूपांतरण स्वचालित करता है (उदाहरण के लिए PostgreSQL) । वे वर्तमान में एक बहुत ही पूर्ण CHUI पर्यावरण का समर्थन करते हैं और वे कोड को दोबारा प्रतिक्रिया देते हैं। उदाहरण के लिए, रूपांतरण UI, डेटा मॉडल और व्यावसायिक तर्क को अलग जावा कक्षाओं में अलग करता है। संपूर्ण परिणाम एक ड्रॉप-इन प्रतिस्थापन है जो मूल के साथ संगत है (उपयोगकर्ताओं को प्रतिरक्षा की आवश्यकता नहीं है, प्रक्रियाओं को संशोधित करने की आवश्यकता नहीं है, डेटा भी माइग्रेट किया जाता है)। यह संभव है क्योंकि वे एक एप्लिकेशन सर्वर और रनटाइम कक्षाओं का एक सेट प्रदान करते हैं जो संगतता प्रदान करते हैं। स्वचालित रूपांतरण का परिणाम ऐसा कुछ नहीं है जिसे आप संकलित और चलाने से पहले आगे संपादन की आवश्यकता हो। सही टर्मिनल समर्थन शामिल है इसलिए हार्डवेयर टर्मिनल अभी भी काम करते हैं (जावा से एनसीयूआरएसईएस तक पहुंचने के लिए इसे एक छोटी जेएनआई लाइब्रेरी की आवश्यकता होती है)। रनटाइम में शेष कोड शेष जावा है। परिणामस्वरूप सिस्टम में कोई प्रगति सॉफ्टवेयर कॉर्प तकनीक का उपयोग नहीं किया जाता है और यह लिनक्स पर चलता है।

कम से कम एक परिवर्तित प्रणाली पहले से ही उत्पादन में है, 24 से 7 मिशन महत्वपूर्ण वातावरण चला रही है। यह एक परिवर्तित ईआरपी प्रणाली है कि उनके मध्यम आकार के पायलट ग्राहक अपने पूरे व्यवसाय को चलाने के लिए उपयोग करते हैं।

संबंधित मुद्दे

 संबंधित मुद्दे