कोड पहले बनाम डेटाबेस पहले

Question

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

मुझे लगता है कि यह मेरे सिर पर अपने वर्कफ़्लो को फ़्लिप करने के बारे में सोच रहा है और यूआई और डेटा मॉडल क्लासेस को पहले इस उम्मीद में बना रहा है कि बाहर काम करने से मुझे यह स्पष्ट हो जाएगा कि मेरा डेटाबेस स्कीमा अंततः कैसा दिखेगा। यह एक अच्छा विचार है? मुझे घबराहट है कि मैं एक यूआई के साथ समाप्त हो जाऊंगा और अभी भी इस बात का कोई विचार नहीं है कि डीबी कैसे तैयार किया जाए।

अगर किसी को उत्सुकता है, तो मैं एसक्यूएल सर्वर को बैकएंड और एमएस एक्सेस के रूप में फ्रंट एंड एप्लिकेशन के रूप में उपयोग कर रहा हूं। (प्रवेश मेरी पसंद भी नहीं है ... इसलिए कृपया इस पर बहुत बुरा न मानें।)

Comments

फ्रंट

— gnat

@ नागट: यह पूरी तरह से अलग है।

— रॉबर्ट हार्वे

यदि यह डुप्लिकेट के रूप में बंद हो जाता है, तो यह इस प्रश्न का डुप्लिकेट होना चाहिए । जो मैं पूछ रहा हूं, उसके अनुरूप उत्तर और प्रश्न अधिक हैं।

— रबरडुक

@ Mawg यह एक कार्य परियोजना है। मैं वापस धक्का दिया है के रूप में ज्यादा के रूप में मैं नीचे आवश्यकताओं को प्राप्त कर सकते हैं। इस पर काम शुरू होना है और इसके अलावा और कुछ नहीं है।

— रबरडुक

इर्रम, नई नौकरी? मुझे पता है कि मैं करूंगा। लेकिन एक 30 साल के फ्रीलांसर के रूप में, मुझे वास्तव में प्रशंसक को मारने से पहले दूर चलना आसान लगता है (कुछ लोग जिन्हें आप सिर्फ "टी हेल्प" कर सकते हैं), लेकिन मुझे लगता है कि यह सभी के लिए इतना आसान नहीं है। यदि आपको कोई तुलनात्मक नियोक्ता नहीं रहना है क्षेत्र में, आदि), लेकिन अगर यह आपको प्रभावित करना शुरू नहीं करता है, तो मत रहो।

— मावग

Answer 1

सबसे पहले क्या आया, प्रक्रिया, या उस प्रक्रिया द्वारा उपयोग किया गया डेटा? मुझे पता है कि यह एक "चिकन या अंडा" सवाल है, लेकिन सॉफ्टवेयर के मामले में, मेरा मानना ​​है कि यह प्रक्रिया है।

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

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

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

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

Comments

"डेटाबेस एक विवरण है"। लिंक के लिए आपका बहुत - बहुत धन्यवाद। मैं पूरे दिल से मानता हूं कि मैं इस परियोजना को उस बात को देखने के बाद एक स्थगित निर्णय के रूप में डेटाबेस से छोड़ने में सक्षम होगा।

— रबरडुक

(यकीनन ये व्यवहार सब कर रहे हैं: और सिर्फ एक नाम है उस पर डाल करने के लिए ) महत्वपूर्ण प्रथाओं चंचल विकास (वृद्धिशील विकास, सबसे सरल बात यह है कि काम कर सकता था, परीक्षण संचालित, उपयोगकर्ता पहले की जरूरत है ...) में।

— sleske

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

— रबरडुक

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

— रॉस प्रेसर

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

— डेविड

Answer 2

एक मूल कारण विश्लेषण से पता चलता है कि यह समस्या विधि में से एक नहीं है, लेकिन एक विनिर्देशन की कमी है। एक के बिना यह वास्तव में कोई फर्क नहीं पड़ता कि आप पहले क्या लिखते हैं - आप इसे वैसे भी फेंकने जा रहे हैं।

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

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

Comments

मैं पूरे दिल से सहमत हूं, लेकिन इस पर ऐसा नहीं होने जा रहा है। हालांकि आपके समय के लिए धन्यवाद।

— रबरडुक

यदि आपके पास इसे करने का समय नहीं है, तो आप इसे करने के लिए समय कहां से पाएंगे?

— वाल्टर मिटी

इसे सही नहीं करने के बारे में कुछ भी कहा था @alterMitty? कृपया स्वीकृत उत्तर में वीडियो लिंक देखें। डेटाबेस एक ऐसा विवरण है जिसे 95% सॉफ्टवेयर से बाहर काम करने के लिए जगह की आवश्यकता नहीं है।

— रबरडैक

मैंने "यह होने वाला नहीं है" का अर्थ यह निकाला कि आप एक सुराग के बिना भी आगे बढ़ने वाले हैं कि सिस्टम से हितधारकों को क्या जानकारी चाहिए। मुझे लगता है कि जेम्स ने आपको विश्लेषण पक्षाघात में बिना मूल प्रणाली विश्लेषण करने के लिए बहुत अच्छी सलाह दी।

— वाल्टर मिती

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

— रबरडुक

Answer 3

मेरा अनुभव इस प्रकार है:

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

यह भी याद रखें:

• यह अब वन-ऐप <-> वन-डेटाबेस वर्ल्ड नहीं है। हो सकता है कि आपके ऐप को एक से अधिक डेटाबेस से डेटा पढ़ना या लिखना होगा या आपके समाधान में एक ही डेटाबेस का उपयोग करके एक से अधिक ऐप शामिल होंगे।

निष्कर्ष: मैं आपको पहले डेटाबेस डिजाइन करने की सलाह देता हूं।

Comments

उन सब बिल्कुल सच बातें हैं, और वास्तव में यह होगा एक "गैर-प्रक्रिया" और स्प्रेडशीट का स्थान ले, लेकिन मैं यह देखने के लिए कि यह कैसे मेरे प्रश्न का उत्तर है असफल। क्या आप स्पष्ट कर सकते हैं?

— रबड़डुक

@RubberDuck मैंने अपने उत्तर के अंत में एक स्पष्टीकरण जोड़ा।

— ट्यूलेंस कोर्डोवा 10

Answer 4

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

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

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

Comments

यह ठीक उसी तरह है जैसे मैं आमतौर पर काम करता हूं। आवश्यकताएँ पहले , हाँ। मैं चाहता हूं कि मैं अभी किसी से कुछ ठोस आवश्यकताओं को खींच सकता हूं।

— रबरडैक

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

— 15

@ साल्स्के - एक अच्छे विश्लेषक को आवश्यकताओं के अधिक "गतिशील" (अर्थात अस्पष्ट और परिवर्तनशील) भागों के लिए एक अनुभव प्राप्त करना चाहिए और आसानी से उपयोगकर्ताओं के साथ सामना करने के लिए डिज़ाइन में कुछ लचीलेपन का निर्माण करना चाहिए।

— जेम्स एंडरसन

@JamesAnderson: असल में, मैं फुर्तीले विकास के सिद्धांतों का बहुत बड़ा प्रशंसक हूं, जहां आप आमतौर पर केवल उसी चीज के लिए डिजाइन करते हैं जो आपको अभी चाहिए , जब तक आप नहीं जानते कि आप बाद में डिजाइन नहीं बदल सकते हैं (शायद ही कभी मामला)। लेकिन मैं ऑफ-टॉपिक जाना शुरू कर रहा हूँ ...

— sleske

Answer 5

चूंकि यह इतना तरल / अनिर्दिष्ट लगता है, मैं पहले GUI को आगे बढ़ाता हूं - जो लगता है कि आपको हितधारकों से प्रतिक्रिया, समर्थन, समय और प्रतिक्रिया प्राप्त करने की आवश्यकता है, है ना? वे आपके शानदार सामान्यीकृत तालिकाओं और विदेशी कुंजी बाधाओं और कैस्केडिंग को हटाने के बारे में परवाह नहीं करते हैं। लेकिन चमकदार रंगों के साथ एक अच्छा जीयूआई - ठीक है, यह शीर्ष पायदान है!

प्रारंभिक बैकएंड "डेटाबेस" के लिए, फ़ाइल के लिए संग्रहित कुछ साधारण, शायद सिर्फ कुंजी / मान का उपयोग करें। मैं एमएस एक्सेस से अपरिचित हूं, इसलिए यह नहीं जानता कि "लाइटवेटीस्ट" बैकएंड क्या होगा। (एक स्प्रेडशीट तालिका?) जो भी त्वरित और गंदा है, उसे फेंकने की योजना बनाएं।

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

अब, शायद आपके हितधारक डीबी विशेषज्ञ हैं - कभी-कभी मेरे साथ भी ऐसा ही होता है! - किस मामले में, कुछ डीबी डिज़ाइन करें।

Comments

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

— k3b

सच है, लेकिन यह उन्हें यह भी विश्वास दिलाता है कि ऐप जितना अच्छा है उतना अच्छा है। मुझे इस तरह से पहले जला दिया गया है और अब मांग है कि हमें सीधे पहली आवश्यकताएं

— मिलें

@Mawg हाँ, दुर्भाग्य से यह एक खतरा है। एक विकल्प (जावा में कम से कम) एक अजीब "देखो और महसूस करो" का उपयोग करना है ताकि यह स्पष्ट हो सके कि यह एक प्रोटोटाइप है।

— user949300

यदि आप नहीं जानते कि आप कहां जा रहे हैं, तो कोई भी कोड आपको वहां मिलेगा।

Answer 6

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

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

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

खोज में देरी हो सकती है क्योंकि आप एक BLOB को क्वेरी नहीं कर सकते हैं ताकि मॉडल स्थिर हो जाए, अपने डेटा को संग्रहीत करना शुरू करें, जिसे रिलेशनल कॉलम में खोजना होगा।

मूल रूप से आप एक सारणीबद्ध मॉडल से शुरू करते हैं और जैसे ही परियोजना आगे बढ़ती है, एक रिलेशनल में चले जाते हैं।

या, किसी भी काम से पहले आवश्यकताओं को मजबूती से शुरू करें ताकि शुरू में एक संबंधपरक मॉडल विकसित किया जा सके।

Comments

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

— रबरडैक

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

— जॉन रेनोर

Answer 7

सामान्य तौर पर मुझे लगता है कि कोड डेटा के बाद आता है क्योंकि कोड डेटा में हेरफेर करने जा रहा है।

यदि आवश्यकताएँ स्पष्ट नहीं हैं, तो आप आवश्यकताओं की अपनी व्याख्या का एक डेटा मॉडल बना सकते हैं। सर्वश्रेष्ठ शायद कुछ आवश्यकताओं को लिखना और अपने नियोक्ता को भेजना है, फिर उनके पास शूट करने के लिए कुछ है। या पहले एक gui बनाएं, यह नियोक्ता के प्रकार पर निर्भर करता है कि क्या सबसे अच्छा काम करता है :)

Comments

इससे पहले किए गए 5 अंकों के बारे में कुछ भी बताने की जरूरत नहीं है और पहले 5 उत्तरों में समझाया गया है

— gnat

मेरी बात ग्राहक के प्रकार के आधार पर दृष्टिकोण का पालन करना है

— कीन IhpleD