हर SQL स्टेटमेंट की समीक्षा डीबीए द्वारा की जाती है - आम?


11

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

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


2
ठीक है, हम कोड में SQL स्टेटमेंट नहीं डालते हैं। हालांकि, सभी कोड की समीक्षा उचित जानकार व्यक्तियों द्वारा की जानी चाहिए।
कैफीक जूल

4
वेब विकास महत्वपूर्ण है। परिणाम सीधे ग्राहक (जो आपके राजा हैं) का सामना कर रहा है, और अधिक बार नहीं, संवेदनशील डेटा वेब सर्वर के लिए सुलभ हैं।
थिटॉन

2
सवाल यह है कि यदि प्रत्येक प्रश्न को डीबीए द्वारा पारित नहीं किया जाता है, तो आप कैसे परिभाषित करते हैं कि डीबीए द्वारा पारित नहीं किया जाना चाहिए और क्या नहीं होना चाहिए।
प्रोग्रामर

6
@thiton: यह एक कंबल कथन है कि सभी वेब अनुप्रयोग सार्वजनिक ग्राहक-सामना कर रहे हैं और संगठन में सबसे महत्वपूर्ण अनुप्रयोग हैं। यह सच नहीं है। कभी-कभी वेब एप्लिकेशन तृतीय-स्तरीय या कम होते हैं (अन्य अनुप्रयोगों की तुलना में)। कुछ का उपयोग केवल एक छोटी, आंतरिक टीमों द्वारा किया जाता है। यह जानने के बिना कि @ DanEllis क्या काम कर रहा है, हम वास्तव में नहीं जानते कि यह वेब विकास कार्य कितना महत्वपूर्ण है।
FrustratedWithFormsDesigner

2
आपको अभी तक नहीं काटा गया है? इस बारे में पूछने पर विचार करें कि यह प्रक्रिया क्यों है ...

जवाबों:


15

मेरी पिछली नौकरियों में मैं (तीन अन्य प्रोग्रामर के साथ) लगभग 40+ प्रोग्रामर के लिए उत्पादन में जाने से पहले बनाई गई या अद्यतन की गई हर संग्रहीत प्रक्रिया की समीक्षा करने के लिए जिम्मेदार था। एक समीक्षक के रूप में यह मेरे समय पर एक वास्तविक खींचतान थी लेकिन कुल मिलाकर अभी भी इसकी आवश्यकता थी क्योंकि इसके साथ कई डेवलपर्स एक बार में एक गलती करेंगे। यह इसलिए आया क्योंकि हमारे पास ऑफ-शोर प्रोग्रामर थे जिन्होंने वास्तव में खराब (कुशल बुद्धिमान) एसक्यूएल स्टेटमेंट लिखे थे और उन्होंने फ्लैट-आउट सीखने से इनकार कर दिया था (वह टीम अंततः बंद हो गई थी)।

कुल मिलाकर हमने देखा:

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

अधिक बार अधिकांश प्रश्नों में कोई समस्या नहीं थी और हमने इसे आगे बढ़ाया। लेकिन प्रत्येक समीक्षा क्वेरी के आधार पर 10 मिनट और दो घंटे के बीच हुई। मेरे हिस्से को रिव्यू करने का विचार पसंद आया क्योंकि इसने खूंखार 2 एएम फोन कॉल को रोक दिया क्योंकि कुछ रिपोर्ट दूसरे एप्लिकेशन के साथ कोई समस्या पैदा कर रही थी। लेकिन एक ही समय में मैंने सोचा कि यह थोड़ा अधिक था क्योंकि हम सभी बड़े हो गए हैं और क्वेरी लिखने वाले व्यक्ति को यह सब करना चाहिए।

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

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


-1 एक महान जवाब लेकिन दुर्भाग्य से सवाल साथी प्रोग्रामर समीक्षा के बाद एक डीबीए द्वारा समीक्षा के बारे में था । यह जवाब वास्तव में सवाल है "सभी कोड की समीक्षा की जानी चाहिए" लेकिन यह सवाल पूछा नहीं गया था। मैं बहुत ज्यादा या इसके बावजूद बाहर नहीं निकलता, केवल जब वे जवाब देते हैं तो सवाल का जवाब नहीं होता।
माइकल डुरंट

बिल्कुल सही। यह कोड है जो पहले ही संदर्भ में समीक्षा कर चुका है । वह महत्वपूर्ण है। अलगाव में एक क्वेरी सहज लग सकती है, लेकिन इसे एक लूप के अंदर डाल दिया और अचानक ऐसा कम है।
इस्वर

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

10

यह पूरी तरह से पर्यावरण, उद्योग और कंपनी पर निर्भर करता है।

कुछ उदाहरण:

  • नासा में, जाँच और समीक्षा के कई स्तर मानक हैं। सबसे अच्छी तरह से ज्ञात "को दोगुना-चेक किया जाना चाहिए" था जब मंगल पर एक जांच को भेजा गया था और अमेरिका ने पैरों में गणना की, लेकिन मीटर में यूरोपीय। जांच खो गई थी।

  • DBA (इन दिनों आम) के साथ एक स्टार्टअप पर कोई DBA समीक्षा नहीं होगी और संभवतः कोई प्रोग्रामर समीक्षा भी नहीं होगी (उदाहरण के लिए, यदि कंपनी में कोई अन्य प्रोग्रामर नहीं हैं)।

  • ऐसी कंपनी में जिसका उत्पाद सैकड़ों-लाखों पंक्तियों का डेटा वेयरहाउस है, यह सुनिश्चित करता है कि प्रश्न कुशल हों और सही हो, व्यापार के मूल में प्रमुख मुद्दे हो सकते हैं जिनकी जाँच होनी चाहिए।

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


5

मैंने कभी इस तरह के माहौल में काम नहीं किया, मुझे यकीन है कि मैं इससे नफरत करूंगा। एक विचार इस के आसपास कुछ मैट्रिक्स का ट्रैक रखने के लिए शुरू करने के लिए आता है ...

  • एक देव को कोड से बाहर sql खींचने और DBA को प्रस्तुत करने के लिए तैयार करने में कितना समय लगता है
  • DBA को sql की समीक्षा करने में कितना समय लगता है?
  • डीबीए द्वारा कितनी बार परिवर्तन का अनुरोध किया जाता है? क्वेरी
    प्रकार से टूट गया ?

बस थोड़ी देर के लिए इस पर नज़र रखने से पता चलता है कि यह कितना प्रभावी है और यह कितना प्रभावी है।


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

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

4

जब डेटाबेस की बात आती है, तो ज्यादातर डेवलपर्स अनजान होते हैं। उन्हें अपनी अज्ञानता का पता भी नहीं है। मैं खुद एक अज्ञानी डेवलपर हुआ करता था।

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

उन्हें पता नहीं है कि एक पूर्ण टेबल स्कैन क्या है। उन्हें पता नहीं है कि कर्सर को खोलने के बजाय एकल सेट ऑपरेशन में डेटा को कैसे संसाधित किया जाए। एक कर्सर से भी बदतर वे डेटा को क्वेरी करेंगे, फिर पंक्ति-दर-पंक्ति प्रक्रिया इसे डेटाबेस में आगे और पीछे ले जा रही है, जब एक एकल सरल प्लेन-अपडेट अपडेट पर्याप्त होगा। HORRIBLE प्रदर्शन में परिणाम।

वे बड़े तालिकाओं के खिलाफ रिपोर्टिंग के गंभीर प्रभावों को नहीं जानते हैं। हो सकता है कि रिपोर्ट की आवश्यकता के लिए एक स्टार स्कीमा और एक डेटा फीड बनाने की आवश्यकता होगी। आपका औसत डेवलपर सिर्फ एक्सिसिट टेबल को क्वेरी करेगा और आश्चर्य होगा कि क्वेरी को चलाने में 3 घंटे लगते हैं (यह एक वास्तविक आंकड़ा है)।

आपके औसत डेवलपर के पास "औसत" CRUD ऐप के लिए पर्याप्त जानकारी होगी, जहां एक उपयोगकर्ता केवल एक रिकॉर्ड संपादित करता है। एक बार जब वे रूबी-ऑन-क्रैक बुलबुले से बाहर निकलते हैं और वास्तविक दुनिया में आते हैं, तो यह पर्याप्त नहीं होगा।


क्या आप किसी भी अधिक होलियर-टू-साउंड करना चाहेंगे?
सेवेंससीट

2
@ कार्पी, कम से कम (ओं) ने अपने अनुभव से ड्राइंग का जवाब देने के लिए समय लिया, बजाय किसी और के जवाब पर बेकार, व्यंग्यात्मक टिप्पणी करने के बजाय, जैसे करपी ने किया।
ड्रयू

2

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


2

मैंने ऐसे माहौल में काम नहीं किया है, न ही मैं करूंगा।

टीम वर्क और शत्रुतापूर्ण नौकरशाही के बीच अंतर है। एक डेवलपर के रूप में, मुझे मुश्किल प्रश्नों पर डीबीए इनपुट पसंद है। लेकिन मुझे पता है कि कब मदद मांगनी है।

यदि मैं सरल SELECTप्रश्नों के लिए पर्याप्त सक्षम नहीं हूं , तो मुझे निकाल दिया जाना चाहिए।


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

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

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

@Telastyn - "औसत डेवलपर नहीं" मैं नहीं खरीदता; मैं अभी भी बुरा डेवलपर्स किराया नहीं कहते हैं। लेकिन हाँ, अगर डीबीए को कॉल प्राप्त करना है, तो मुझे थोड़ी अधिक सहानुभूति है।
नाथन लॉन्ग

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

2

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

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

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


2

मैंने उस तरह के वातावरण में काम किया है। सभी सिस्टम परिवर्तन उपयुक्त साथियों द्वारा समीक्षा किए गए थे। मेरे लिए बस इसका मतलब था कि मुझे आगे की योजना बनानी थी और कुछ दिन पहले ही अपने बदलाव जमा करने थे। SQL DBA में चला गया जो अंततः SQL को उत्पादन में छोड़ देगा।

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


0

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

इसके अलावा अनुभवहीन डेवलपर्स ORM के दुरुपयोग के साथ डेटाबेस को अपने घुटनों तक खींच सकते हैं या एक क्वेरी जो इष्टतम से बहुत दूर है।

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


0

हमारी विकास टीम में 4 डेटाबेस डेवलपर्स की एक उप-टीम है जो हमारे द्वारा उपयोग किए जाने वाले डीबीएमएस प्लेटफॉर्म में अनुभवी है। वे सभी एसक्यूएल या कम से कम समीक्षा लिखते हैं और अपने कोडिंग मानकों को पूरा करने के लिए बदलाव करते हैं। नेट डेवलपर्स द्वारा लिखित किसी भी एसक्यूएल। वे प्रोजेक्ट टीम का हिस्सा हैं। उत्पादन डीबीए पूरी तरह से अलग विभाग से संबंधित है और उनकी नौकरी चालू है। वे हमारे एसक्यूएल कोड या स्कीमा की समीक्षा नहीं करते हैं और यहां तक ​​कि तैनाती को स्क्रिप्टेड किया जाता है, वे सभी स्क्रिप्ट चलाते हैं। सबसे ज्यादा मदद उन्हें परफॉर्मेंस ट्यूनिंग में मिलती है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.