2009-09-29 12 views
8

ज्यादातर लोग क्यों कहते हैं कि डेटा सेवाओं और डेटाबेस सिस्टम के सबसे महत्वपूर्ण भाग हैं?ज्यादातर लोग क्यों कहते हैं कि डेटा सेवाओं और डेटाबेस सिस्टम के सबसे महत्वपूर्ण भाग हैं?

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

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

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

मेरा मानना ​​है कि यूआई (जावा या सी # में) बनाने वाले डेवलपर्स के पास डेटाबेस ज्ञान होना चाहिए। यह उन्हें पूरे आवेदन का निर्माण करने देगा। मेरे विचार में, गैर-डेटाबेस ज्ञान व्यक्ति को वैसे भी एप्लिकेशन विकसित करना असंभव है।

कृपया मुझे बताएं कि मैं यहां क्या खो रहा हूं।

बहुत बहुत धन्यवाद।

+1

मैं नहीं कह रहा हूं कि डेटाबेस अंत है या सभी हो, लेकिन कृपया, पूछने से पहले असली दुनिया में काम करें। –

+0

डाउनवोट को समझ में नहीं आता है। सिर्फ इसलिए कि प्रश्न थोड़ा छोटा दिखता है इसका मतलब यह नहीं है कि यह एक अमान्य प्रश्न है। +1। –

+0

सवाल क्या है? डेटाबेस कहता है कि हर कोई कौन सबसे महत्वपूर्ण है? किस तरह की प्रणाली? यह सवाल क्यों महत्वपूर्ण है? –

उत्तर

11

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

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

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

10

मैं सामने के छोर की ओर विश्वास है: जीयूआई, WebUI, XAML मध्य स्तरीय और डेटाबेस स्तरीय से ज्यादा महत्वपूर्ण है।

यह कहने की तरह है कि एक कार का रंग इंजन और टायर से अधिक महत्वपूर्ण है।

शायद यह डेटाबेस बनाने के लिए एक बड़ा सौदा नहीं है। हालांकि, यह एक सही तरीके से निर्माण करने, मौजूदा एक को अनुकूलित करने और एक अच्छी तरह से डिज़ाइन किए गए डेटा स्टोर को बनाए रखने का एक बड़ा सौदा है। आईएमओ, यही कारण है कि डेटाबेस/डेटास्टोर लोगों को बड़ी रकम मिलती है।

+1

से पूरी तरह से सहमत हूं, लेकिन, कार गीक्स (और संभवतः सामान्य गीक, मुझे शामिल किया गया है, और मुझे कारों के बारे में कुछ नहीं पता) दुनिया का एक अच्छा हिस्सा कार के रंग को देखता है और उन छोटी/कॉस्मेटिक चीजें बना सकती हैं या एक सौदा तोड़ो। –

+1

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

+1

युगोस बेच नहीं पाए क्योंकि वे बदसूरत * और * अविश्वसनीय थे। यदि टायर 20 मील प्रति घंटे से ऊपर विस्फोट करते हैं तो कितने लोग एक सुंदर कार खरीदेंगे? "मुझे अपने कमल एलिस से प्यार है, लेकिन हाईस्कूल ट्रैक टीम मुझे बेकार कर रही है। व्हासअप बुद्धि डेट?" – DaveE

2

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

5

यह सब महत्वपूर्ण है।

2

डेटाबेस ज्ञान व्यक्ति को किसी भी एप्लिकेशन को विकसित करने के लिए असंभव है।

यदि आप वेब सेवाओं में लिपटे संग्रहित प्रक्रियाओं के साथ डेटाबेस टेबल को छिपाते हैं तो नहीं।

फ्रंट एंड वास्तविक एप्लिकेशन पर केवल एक त्वचा है।

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

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

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

+0

यदि आप वेब सेवाओं में लिपटे संग्रहीत प्रक्रियाओं के साथ डेटाबेस टेबल को छिपाते हैं तो यक! मैं एसओए के लिए बिल्कुल उपयुक्त हूं, लेकिन वेब सेवाओं के साथ सबकुछ कर रहा हूं + संग्रहित प्रोसेस एक बहुत ही प्रक्रियात्मक डिजाइन बन जाता है। – fregas

+0

आप कैसे समझते हैं? – CaffGeek

4
है कि आप एक साथ फेंक डेटाबेस है कि महत्वपूर्ण नहीं लगता है, लेकिन यह है कि एप्लिकेशन बढ़ने और समय के साथ विकसित करते हैं और आप तेजी से गरीब डिजाइन के कारण नुकसान में चलाने एक छोटा सा ऐप्लिकेशन के लिए

डेटाबेस परत और मध्यम स्तरीय लंबी उम्र और अपने अनुप्रयोग के रख-रखाव के लिए चाबियाँ हैं।

1

व्यवसाय का तर्क हमेशा जे 2 ईई या डॉटनेट उद्यम ढांचे सहायता के साथ सरल होना चाहिए।

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

7

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

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

+0

+1 - अच्छी टिप्पणी - इच्छा है कि मैं दो बार ऊपर उठा सकता हूं। –

+0

डेवलपर के लिए +1! = डिजाइनर –

+0

हालांकि मुझे सूर्य ब्लू प्रिंट – ariso

2

आपके गैर-प्रश्न का उत्तर देना असंभव है।

यह एक आधार पर आधारित है कि हर कोई सोचता है कि डेटाबेस सभी प्रणालियों में सबसे महत्वपूर्ण बात है - जो गलत है, जाहिर है - न केवल सभी लोग सोचते हैं कि, कई सिस्टम डेटाबेस का उपयोग नहीं करते हैं और कई अनुभवी लोग सहमत हैं कि विभिन्न प्रणालियों के सबसे महत्वपूर्ण भाग सिस्टम से सिस्टम में भिन्न होते हैं।

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

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

उसी तरह एक इंजन एक पेंट जॉब की तुलना में अधिक महंगा है, तो मुझे उम्मीद है कि हम पेंट के रंगों के चयन के बजाय लोगों को डिज़ाइन इंजनों के लिए अधिक भुगतान करेंगे।

सभी प्रणालियों में विशिष्टताओं और जटिलताओं का एक स्पेक्ट्रम है।

0

इसका मतलब यह नहीं है कि सभी लोग वीसी ++ में अच्छी तरह से कोड कर सकते हैं, भले ही उनके पास सी ++ में ज्ञान हो।

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

यह सब अनुभव और आपकी विशेषज्ञता के साथ आता है। याद रखें कि वे डीबीए करने के लिए अच्छी तरह से भुगतान करते हैं, यूआई डिज़ाइन नहीं करते हैं।

इसका मतलब यह नहीं है कि यूआई डेवलपर्स डीबी डिज़ाइन नहीं कर सकते हैं। यदि आपके पास डेटाबेस डिज़ाइन के साथ पर्याप्त अनुभव है, तो आप भी एक अच्छा डीबी डिजाइनर बन सकते हैं।

+0

में भी अच्छा मध्य स्तरीय डिज़ाइन दिखाई नहीं देता है, इस बातचीत में सी ++ कहां आया? मुझे लगता है कि एक व्यापार अनुप्रयोग में सी ++ का उपयोग कर सुंदर पुरातन है। – fregas