इस तरह की बात एक जगह से दूसरी जगह बदलती रहती है। मेरी वर्तमान साइट पर, डेवलपर्स और डीबीए के बीच की रेखा वास्तव में बहुत धुंधली है - हम (डीबीए) पीएल / एसक्यूएल भी लिखते हैं, और वे (डेवलपर्स) क्वेरी योजनाओं को विच्छेदित करते हैं। हम सभी अपने आप को सहकर्मी के रूप में देखते हैं, केवल विभिन्न कौशल और जिम्मेदारियों के साथ। यह बहुत ही मनोरंजक है: हाल ही में कंपनी ने DevOps बैंडवागन को ऑन-बोर्ड किया है । डेटाबेस समुदाय इसे बिल्कुल नहीं समझता है; हमने हमेशा उसी तरह काम किया है। कहने की जरूरत नहीं है कि हम इस तरह से काम कर रहे हैं: डेटाबेस टियर दूर हैकंपनी के प्रौद्योगिकी स्टैक का सबसे विश्वसनीय हिस्सा, इसे संचालित करना आसान है (क्योंकि हमारे पास डीबीए टीम में कौशल को एक गहरे स्तर पर आवेदन समझने के लिए है, और डेवलपर्स के पास 24/7/365 संचालन और कैसे समझने के लिए डीबीए एक्सपोज़र है इसके लिए उनके ऐप्स को तैयार करना)।
लेकिन मुझे पता है कि जब आप डेवलपर के "गलत" प्रकार के बारे में बात करते हैं तो आपका क्या मतलब है। वह स्व-सिखाया जाता है, जो अपने आप में एक नेक काम है, लेकिन जिस तरह से वह किसी भी तरह के औपचारिक निर्देशों का अविश्वास उठाता है। वह नहीं जानता कि वह क्या नहीं जानता है , और वह किसी को भी उसे समझाने की कोशिश करता है, वह इसे अपने आत्म-सीखने के कौशल के अपमान के रूप में देखता है। उन्होंने प्रोग्रामिंग की अनिवार्य शैली सीख ली है, क्योंकि आप इसे बिना किसी सिद्धांत सिद्धांत के सीख सकते हैं कि सीएस प्रकार हमेशा के बारे में बड़बड़ा रहा है (अच्छी तरह से, बुरी तरह से, हर किसी को बड़े-ओ को जानने की जरूरत है ;और सिद्धांत के समान बिट्स)। उन्होंने OO का एक सा भी सीखा है, सिर्फ इसलिए कि उन्हें जावा का उपयोग करना है। लेकिन एक अच्छा डेटाबेस पेशेवर - डेवलपर या डीबीए - को एक घोषणात्मक शैली में आरामदायक सोच, सेट सिद्धांत, सामान्य रूपों, यहां तक कि संबंधपरक बीजगणित और कैलकुलस को समझने में सक्षम होने के बारे में सोचना पड़ता है। इन लोगों के साथ संवाद करना बहुत, बहुत मुश्किल है, क्योंकि वे सक्रिय रूप से किसी भी चीज़ के प्रति शत्रुतापूर्ण हैं जो उन्हें उनके आराम क्षेत्र से बाहर कर सकता है, जो कि एक वेब पेज पर कुछ प्रारूपित करने के तरीके से बड़ा और सीमित है। यदि वे सभी डेटाबेस के बारे में सोचते हैं, तो वे सोचते हैं कि एक तालिका एक कक्षा की तरह है और एक पंक्ति एक वस्तु की तरह है। ये लोग शाब्दिक रूप से बस करेंगे SELECT * FROM TABLEऔर अपने कोड में परिणामों को फ़िल्टर और सॉर्ट करेंगे। वे वास्तव में, वास्तव में समझ में नहीं आता है कि एक डेटाबेस एक फ्लैट फ़ाइल से बेहतर क्यों है (और वे नहीं-तो-गुप्त रूप से सोचते हैं कि जो कोई संबंधपरक डेटाबेस का उपयोग करता है वह एक बेवकूफ है)।
मैं आपको एक वास्तविक उदाहरण देता हूं: हाल ही में मैं इनमें से एक प्रकार के मुद्दों पर बात कर रहा था, जो हमारे सॉफ्टवेयर के रिलीज को वापस लाने में शामिल थे, जब यह उत्पादन में चला गया था, तो एक मुद्दा पिछले क्यूए से फिसल गया था। मैंने समझाया कि जब हम उसके एप्लिकेशन (डेटाबेस तक पहुंचने वाले कई में से एक) को रोल कर सकते हैं, तो उसे अभी भी तैनात डेटाबेस के साथ काम करने में सक्षम होने की आवश्यकता होगी। उन्होंने पूछा कि क्यों, और मैंने कहा, ठीक है, उन नए तालिकाओं और स्तंभों में, वास्तविक ग्राहक डेटा होगा। उसने फिर कहा, इसलिए इसे एक अस्थायी तालिका में कॉपी करें, क्या समस्या है। मैंने उसे अविश्वास में घूरते हुए कहा: जब एक ग्राहक कहता है और कहता है, मेरे खाते से मेरे पैसे गायब हो गए हैं, तो हम उसे क्या बताते हैं, कि यह ठीक है, यह एक अस्थायी तालिका में है? उसे बस यह नहीं मिला कि जब आप दूसरे लोगों के पैसे का लेन-देन कर रहे हैं, तो आपको एक जिम्मेदार वयस्क की तरह काम करना होगा। सभी के लिए मुझे पता है कि वह अभी भी नहीं करता है; वह अब हमारे साथ नहीं है।
MySQL शिविर एक लंबे समय के लिए इस तरह थे; वे कहेंगे कि आपको लेन-देन, विदेशी चाबियों आदि की आवश्यकता नहीं थी, अगर आपको लगता है कि आपने ऐसा किया था, क्योंकि आपको पता नहीं था कि आप क्या कर रहे थे, आदि, आदि (फिर जब वे बड़े हो गए, तो उन्होंने चुपचाप उन्हें जोड़ा)। ये ऐसे प्रकार के लोग हैं जिनके लिए ActiveRecord या Hibernate जैसे ORMs विकसित किए गए थे, इसलिए वे SQL को छूने की आवश्यकता के बिना डेटाबेस एप्लिकेशन लिख सकते थे। इन तकनीकों का उपयोग मैं लाल झंडा मानता हूं - यह एक कंपनी नहीं है जो डीबीए कौशल को महत्व देती है। वे वास्तव में क्या चाहते हैं एक दाई ...