अनुभवी प्रोग्रामर को डेटाबेस क्वेश्चन जानना चाहिए? [बन्द है]


35

वहाँ बहुत सारे प्रोग्रामर हैं जो क्वेरी लेखन और डेटाबेस डिज़ाइन के विशेषज्ञ भी हैं।

क्या एक विशेषज्ञ प्रोग्रामर या सॉफ्टवेयर इंजीनियर बनने के लिए यह एक मुख्य आवश्यकता होनी चाहिए?

यद्यपि क्वेरी और कोड विकसित करने के तरीके में बहुत सारी समानताएं हैं, मेरी व्यक्तिगत राय है, क्वेरीज़ में कोड की तुलना में एक अलग संरचना है और यह अलग-अलग दृष्टिकोणों के कारण एक साथ मास्टर दोनों के लिए कठिन हो सकता है।


2
"संरचना" से आपका क्या तात्पर्य है? यदि आप शब्दार्थ के बारे में बात कर रहे हैं, तो किसी भी प्रकार के नए शब्दार्थ को समझने के बजाय " विशेषज्ञ " के लिए समस्या नहीं होनी चाहिए । परिभाषा से। ओटीओएच, केवल कुछ ही डेवलपर्स डेटाबेस और क्वेरी भाषाओं के संपर्क में हैं, हम में से बाकी बिल्कुल परवाह नहीं करते हैं।
तर्क

3
मुझे लगता है कि यह एक गलत धारणा है: "वहाँ बहुत सारे प्रोग्रामर हैं जो क्वेरी और डेटाबेस डिज़ाइन के विशेषज्ञ भी हैं।" अपेक्षाकृत कम प्रोग्रामर हैं जो इन चीजों के विशेषज्ञ हैं: डीबीए! = एसई।
एशले

1
डेटाबेस क्वेश्चन लिखना कितना मुश्किल है?
कैप्टन सेंसिबल

@CaptainShakespeare, सीआरयूडी के पिछले ऑपरेशनों को प्राप्त करने के बाद वास्तव में यह काफी मुश्किल हो सकता है। Ty कुछ समय के बाद जटिल रिपोर्टिंग कर रहा है। और फिर प्रदर्शन ट्यूनिंग प्रश्नों को देखें।
HLGEM

जवाबों:


69

डेटाबेस क्वेरी लेखन एक मुख्य आवश्यकता होनी चाहिए या नहीं, यह नौकरी पर निर्भर करता है, लेकिन संबंधपरक डेटाबेस वर्तमान तकनीक में सर्वव्यापी हैं।

इसलिए, अगर मैं एक प्रोग्रामर से मिला, जो डेटाबेस क्वेश्चन लिखना नहीं जानता था, तो मुझे दो चीजों में से एक की उम्मीद होगी:

  1. वे आम तौर पर अनुभवहीन हैं।
  2. वे एक अन्य क्षेत्र (जैसे एम्बेडेड सिस्टम) में अत्यधिक विशिष्ट हैं और इसे सीखने की कभी आवश्यकता नहीं है।

डेटाबेस प्रश्न मूलभूत रूप से अधिक मानक प्रोग्रामिंग भाषाओं से अलग हैं। वे बीजीय हैं और संबंधपरक डेटा पर काम करने का इरादा रखते हैं, जबकि C # या Java अनिवार्य हैं और डिस्क, मेमोरी, उपयोगकर्ता इनपुट आदि पर काम करते हैं। यहां तक ​​कि LISP या हास्केल जैसी कार्यात्मक भाषाएं जो रूप में अधिक बीजीय हैं, रिलेशनल डेटा के लिए कम उन्मुख हैं।

संपादित करें: जैसा कि मेरे और अन्य लोगों द्वारा टिप्पणियों में बताया गया है, कुछ मान्य कारण हैं कि एक अनुभवी डेवलपर डेटाबेस प्रश्नों को नहीं जान सकता है:

  • उनकी टीम ने ORM / NoSQL का उपयोग किया
  • उनकी टीम में डीबी प्रोग्रामर थे
  • आवेदन की जटिलता व्यावसायिक तर्क में थी, और DB प्रश्न तुच्छ थे
  • उनकी टीम ने इस तरह के काम को लागू किया कि कुछ प्रोग्रामर ने प्रश्न नहीं लिखे

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

सारांश में, अधिकांश अनुभवी डेवलपर्स को डेटाबेस प्रश्नों को जानना चाहिए


1
इसलिए, यदि किसी ने गैर-तुच्छ परियोजना का उपयोग किया है जो डेटाबेस का उपयोग करता है, तो उसे प्रश्नों से परिचित होने की उम्मीद है, है ना?
शमीम हाफिज

3
@ शमीम, मैं उम्मीद करूंगा कि यह व्यक्ति प्रश्नों के साथ मामूली रूप से अनुभवी होगा जब तक कि यह व्यक्ति एक जूनियर या प्रवेश स्तर नहीं था। शायद इस व्यक्ति के पास केवल कुछ वर्षों का अनुभव है और एक अति विशिष्ट टीम में आश्रय था?
maple_shaft

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

4
मेरी विकास टीम ने परियोजना के हिस्से के रूप में PL / SQL प्रोग्रामर को समर्पित किया है। इसलिए जबकि .Net प्रोग्रामर सरल प्रश्न कर सकते हैं, वे इसकी समीक्षा करने और अधिक जटिल प्रश्नों को विकसित करने के लिए हैं। ORM (और NOSQL) के प्रसार के साथ-साथ आपको क्यों लगता है कि गैर-SQL डेवलपर्स को जटिल प्रश्नों को जानना चाहिए।
मुलायम a

2
@ मैथ्यू रोडाटस: मैंने उन जगहों पर काम किया है, जहां पुस्तकालयों की व्यवस्था थी, जो प्रश्नों का प्रबंधन करते थे, इसलिए साधारण एसक्यूएल को समझे बिना वहां काम करना सैद्धांतिक रूप से संभव होगा। मेरा मानना ​​है कि सभी डेवलपर्स व्यवहार में इसमें सक्षम थे।
डेविड थॉर्नले

23

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

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


1
सौभाग्य से, आजकल किसी भी RDBMSes के बिना आवेदन करना पूरी तरह से ठीक है। अधिकांश कार्यों के लिए उनकी आवश्यकता नहीं होती है, या बस एक संबंधपरक मॉडल के लिए पर्याप्त रूप से मैप नहीं किया जा सकता है। गैर-संबंधपरक भंडारण विकल्प उपलब्ध हैं।
तर्क

8
यह मेरी राय के अनुसार भी है। विशेषज्ञ? जानकारी नहीं? हाँ।
वेन मोलिना

2
@ एसके-तर्क, आप किस तरह के विकल्पों को संबंधपरक डेटाबेस को अप्रासंगिक बनाते हैं? डेटावेयर एक विश्लेषण प्रणाली में उपयोगी होने के लिए बहुत उपयोगी है। और मुझे OODBMS के साथ सब कुछ गलत होने पर शुरू न करें।
maple_shaft

1
@maple_shaft, कई विशिष्ट, डोमेन-उन्मुख भंडारण समाधान हैं। RDBMSes सामान्य होने की कोशिश करता है, और इसमें बुरी तरह से विफल रहता है। कुछ मामलों में भी प्राचीन श्रेणीबद्ध डीबीएमएस रिलेशनल से बहुत बेहतर हैं।
एसके-लॉजिक

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

18

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

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

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

प्रोजेक्ट्स अक्सर परेशानी में पड़ जाते हैं क्योंकि वे इन लोगों को तब तक नौकरी पर नहीं रखते हैं जब तक कि डेटाबेस के 100,000,000 रिकॉर्ड न हों और धीरे-धीरे चल रहे हों। या वे उपकरण को खराब होने के लिए दोषी मानते हैं (कोई SQL सर्वर धीमा नहीं है यदि आप सही तरीके से डिज़ाइन करते हैं) उनकी डिज़ाइन अक्षमता नहीं।


4
+1 यह उल्लेख करने के लिए कि ओआरएम की उपस्थिति एसक्यूएल (या जो भी प्रकार का डीबी उपयोग कर रहा है) में अंतर्निहित कारकों को जानने की आवश्यकता को प्रतिस्थापित नहीं करता है।
RHSeeger

4
+1 और मैं चाहता हूं कि मैं आपको 100 और दे सकूं! मुझे पता है कि राज्याभिषेक! = कारण है, लेकिन यह मेरे लिए अधिक स्पष्ट है कि मैंने जो सबसे प्रभावी अनुप्रयोग डेवलपर्स के साथ काम किया है, वह पूरी तरह से एक मानक चयन क्वेरी लिखने की समझ रखता था। मुझे एक अच्छे डेवलपर को डेटा मॉडल और डेटा के बारे में एक "प्रश्न" सौंपने में सक्षम होना चाहिए और उस व्यक्ति को अंततः मेरे प्रश्न का उत्तर "प्रश्न" लिखने में सक्षम होना चाहिए।
maple_shaft

1
+1, पूरी तरह से सहमत हैं। मैं इस स्पष्टीकरण को नहीं खरीदता हूं कि 'हम ORM का उपयोग करते हैं' या 'हमारे पास इसके लिए प्रोग्रामर समर्पित हैं'। यदि कोई वास्तव में अनुभवी है , तो उन्होंने एक बिंदु पर db डेवलपर की भूमिका को भरा होगा। यह अनुभव क्या है
ग्रैंडमास्टरबी

15

राजनीतिक रूप से सही उत्तर: यह निर्भर करता है। यदि डेवलपर कभी रिलेशनल डेटाबेस के साथ काम नहीं करता है (और इस दिन और NoSQL अनुप्रयोगों की उम्र में, जो वास्तव में काफी संभावना है) तो SQL ज्ञान का कोई मूल्य नहीं है।

दूसरा, जब कोई डीबीए या पूर्णकालिक क्वेरी लेखक (जो भी शीर्षक है), तो समझ का भी कम महत्व नहीं है।

यह वास्तव में केवल महत्वपूर्ण है अगर डेवलपर को जैक-ऑफ-ऑल-ट्रेड होने की आवश्यकता है और रिलेशनल डेटाबेस का उपयोग करने के लिए उसकी परियोजनाओं में आवश्यकता है (उदाहरण के लिए पुराने जमाने के वेब अनुप्रयोगों में या मौजूदा डेटाबेस से जुड़ना)

मेरी व्यक्तिगत राय: नहीं। एक अनुभवी सॉफ्टवेयर डेवलपर को एक नया कौशल (जैसे एसक्यूएल) सीखने में सक्षम होना चाहिए, अगर उन्हें जरूरत पड़ने पर 'डिफ़ॉल्ट रूप से' नहीं। लचीलापन और सीखने और समझने की क्षमता, यह है, जो एक अच्छा डेवलपर को एक ठीक से अलग करता है। 'गोल्डन हैमर' नियम भी लागू होता है - यदि आपके पास व्यापक SQL ज्ञान वाला एक डेवलपर है, तो यह बहुत संभावना है कि यह डेवलपर उस टूल को खींच लेगा जिसे वह सबसे अच्छा जानता है - संबंधपरक डेटाबेस - हर समस्या को हल करने का प्रयास करने के लिए, जबकि यह जरूरी नहीं है सबसे अच्छा समाधान हो। बेशक, यह NoSQL अधिवक्ताओं पर भी लागू होता है;)।

सही काम के लिए सही उपकरण चुनना एक अनुभवी प्रोग्रामर को पता होना चाहिए।


NoSQL डेटाबेस रिलेशनल डेटाबेस की तुलना में अधिक डेटा या तेज़ प्रक्रिया नहीं करता है। मुझे नहीं पता कि आपने कहाँ सुना है, लेकिन यह स्पष्ट रूप से, खतरनाक रूप से गलत है।
आरोन

@Aaronaught - संपादित, मेरे समयपूर्व अनुमान के शीर्ष-अप के लिए धन्यवाद, :)।
कुलथु

7

कंप्यूटर प्रोग्रामिंग के लिए इस विकिपीडिया परिचय की जाँच करें:

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

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

तो मुझे लगता है कि यह प्रोग्रामिंग है, निश्चित रूप से।


7

एंटरप्राइज़ और व्यावसायिक अनुप्रयोगों (EDIT: विशेष रूप से परियोजनाओं में RDBMS का उपयोग करने वाली पृष्ठभूमि) के साथ एक अच्छा सॉफ्टवेयर इंजीनियर मानक प्रारूप में रिलेशनल डेटाबेस क्वेरी लिखने का विशेषज्ञ ज्ञान होना चाहिए। इसके अलावा वे जटिल स्कीमा को समझने और कम से कम मध्यम जटिलता के स्कीमा डिजाइन का प्रस्ताव करने में सक्षम होना चाहिए।

अत्यंत उन्नत या जटिल स्कीमा डिज़ाइन एक डेटा मॉडलर या कार्यात्मक वास्तुकार का क्षेत्र होना चाहिए।

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

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


2
-1: दृढ़ता से असहमत हैं कि "अच्छा" सॉफ्टवेयर इंजीनियर रिलेशनल डेटाबेस प्रश्नों का विशेषज्ञ होना चाहिए ।
जॉन सॉन्डर्स

3
क्या आप अभी भी असहमत होंगे अगर मैं कहूं कि एक अच्छा उद्यम या व्यवसाय अनुप्रयोग सॉफ्टवेयर इंजीनियर (एम्बेडेड सिस्टम, आदि के विपरीत ...) और अगर मैंने कहा कि यह व्यक्ति STANDARD रिलेशनल डेटाबेस प्रश्नों (बिना फैंसी-पैंट विक्रेता के एक विशेषज्ञ होना चाहिए) विश्लेषणात्मक प्रश्नों और इसी तरह की विशिष्ट)? SQL सेलेक्ट स्टेटमेंट्स, सभी प्रकार के जॉन्स, यूनियनों, चौराहों और मर्जों, इनलाइन व्यूज़, कंडीशन, ऑर्डरिंग और ग्रुपिंग रिजल्ट सेट्स की गहन समझ को किसी भी सॉफ्टवेयर इंजीनियर द्वारा अच्छी तरह से समझा और प्रदर्शित किया जाना चाहिए जो कि ऊपर बताए गए लेबलों को वहन करता है।
maple_shaft

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

2
मैंने जो कहा मैं उसपर अडिग हूँ। सैद्धांतिक रूप से यदि एप्लिकेशन को अच्छी तरह से कंपेयर और कंपेयर किया गया है, तो मेरे पूरे प्रोफेशनल एक्सपीरियंस में मेरी टीम की कोई जरूरत नहीं है और अगर हमारे पास RDBMS डिजाइन और डेवलपमेंट के लिए डेडिकेटेड टीम थी, तब भी मुझे DROWNED की जरूरत नहीं होगी। शायद मैं पुराने जमाने का हूं या मेरे करियर में बस भयानक किस्मत है?
maple_shaft

3
@maple_shaft हाँ, ऐसा नहीं है कि जिन अनुप्रयोगों पर मैंने काम किया है, वे पर्याप्त रूप से संकलित किए गए थे। यह है कि उन्होंने किसी भी RDBMS, अवधि का उपयोग नहीं किया। विभिन्न क्षेत्रों, मुझे लगता है। मुद्दा यह है कि आप यह नहीं कह सकते हैं कि प्रत्येक व्यवसाय / उद्यम डेवलपर SQL में अच्छा होना चाहिए। यह सच नहीं है। यदि आप इसका उपयोग करते हैं तो यह अच्छा होगा। अगर आपको इसकी आवश्यकता नहीं है, तो किसी भी अन्य भाषा या प्रौद्योगिकी के साथ बहुत चिंता न करें।
एडम लेअर

6

अन्य लोगों ने पहले ही डेटाबेस प्रश्नों के बारे में आपके प्रश्न का उत्तर दे दिया है।

डेटाबेस डिजाइन एक विशेष प्रकार का डिजाइन है। यह सीखना मुश्किल नहीं है, लेकिन विशिष्ट डेटाबेस डिज़ाइनर को डेटाबेस को डिज़ाइन करने के कई अवसर नहीं मिलते हैं।

जिस स्थान पर मैं अब काम कर रहा हूं, उसमें वही डेटाबेस डिज़ाइन है जो 1970 में था। हमने डेटाबेस को IDMS से DB2 में स्थानांतरित कर दिया है, लेकिन यह समान नेटवर्क डेटाबेस डिज़ाइन है। मुझे यहां काम करने वाले 9 वर्षों में 5 नए डीबी 2 टेबल बनाने का अवसर मिला है।

मुझे संदेह है कि एक समर्पित डेटाबेस डिजाइनर के साथ बहुत कम कार्य स्थान हैं। इसलिए, मैं यह निष्कर्ष निकालता हूं कि डेटाबेस डिजाइन को एक वरिष्ठ विश्लेषक के प्रदर्शनों का हिस्सा माना जाता है।


5

मैं काफी स्पष्ट रूप से आश्चर्यचकित हूं कि हम में से बहुत से लोग सोचते हैं कि हर विकास एक डेटाबेस और एक SQL डेटाबेस के चारों ओर घूमता है।

अन्य लोगों ने कई तरीकों का उल्लेख किया है जिसमें हम अपनी नौकरियों में SQL के किटी-ग्रिट्टी से बच सकते हैं, भले ही हम डेटाबेस के साथ (अप्रत्यक्ष रूप से) काम कर रहे हों, लेकिन उन सभी डेवलपर्स के बारे में जो 101 विद्युत उत्पादों के लिए फर्मवेयर लिखते हैं, जिनमें से प्रत्येक अधिकारी? वास्तविक समय की निगरानी में विशेषज्ञता वाले लोगों के बारे में क्या?

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


5

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

कई वर्गों के आवेदन डेटाबेस-केंद्रित नहीं हैं।

क्या हमें अब वर्ड प्रोसेसर और इमेज एडिटर में DBMS की जरूरत है? वाक् पहचान और कंप्यूटर विज़न सिस्टम के बारे में क्या इनमें बहुत सारे डेटाबेस प्रश्न हैं?

और क्या रैखिक वीडियो संपादकों और वीडियो गेम भौतिक इंजन?


5

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


4

मुझे नहीं लगता कि क्वेरी लेखन प्रोग्रामर के लिए एक मुख्य आवश्यकता होनी चाहिए। ऐसा कहने के बाद, मेरा मानना ​​है कि एक प्रोग्रामर जो प्रश्न लिख सकता है और डेटाबेस डिजाइन कर सकता है, वह किसी संगठन के लिए अधिक मूल्यवान होगा।

हालाँकि, यदि यह प्रोग्रामर केवल "tblxxxx से" सेलेक्ट लिख सकता है "टाइप क्वेश्चन मैं इस प्रोग्रामर को एक्सपर्ट नहीं मानूंगा। इसी तरह, अगर इस प्रोग्रामर द्वारा डिज़ाइन किया गया डेटाबेस दो टेबल के बजाय एक-से-एक कई संबंधों को एक टेबल में रखता है तो मैं इस प्रोग्रामर को विशेषज्ञ नहीं मानूंगा।

यहाँ मैं इसे गैर आईटी लोगों को कैसे समझाऊं। आईटी पेशेवर कुछ क्षेत्रों में विशेषज्ञता रखते हैं कि कैसे बढ़ई, बिजली और प्लंबर वहां सम्मानित क्षेत्रों में विशेषज्ञ हैं। वे कुछ कौशल को ओवरलैप करने की प्रवृत्ति रखते हैं लेकिन सभी क्षेत्रों में विशेषज्ञ नहीं हैं। एक इलेक्ट्रीशियन विश्वास के साथ सरल बढ़ईगीरी कार्य कर सकता है लेकिन जटिल संरचनाओं से निपटने के लिए अच्छी तरह से कोशिश नहीं करेगा।

इसी तरह, एक प्रोग्रामर को पता होना चाहिए कि कैसे सरल प्रश्नों और डेटाबेस डिज़ाइनों को लिखना या हेरफेर करना है, लेकिन एक जटिल डेटा संरचना को डिज़ाइन करने की अपेक्षा नहीं की जाती है।


3

हमारे विभाग में चारों ओर देखना, यह निर्भर करता है:

  • हमारे डेस्कटॉप / वेब / सर्वर डेवलपर्स । उनकी विशेषता के आधार पर कम से कम उन्नत से उन्नत क्रूड स्टेटमेंट लिखना आवश्यक है। अनुकूलन के लिए हमारे पास कुछ विशेष डीबी व्यवस्थापक हैं।
  • हमारे एम्बेडेड प्रोग्रामर । काफी कुछ पिछले कभी नहीं मिला "mytable से" का चयन करें। हालाँकि, यह भी पिछले कुछ महीनों में बदल गया अपनी परियोजनाओं के लिए sqllite की शुरूआत के साथ ।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.