अगर मैं ORM फ्रेमवर्क को अच्छी तरह से जानता हूं तो SQL महत्वपूर्ण है? [बन्द है]

50

मुझे SQL में कोई गंभीर अनुभव नहीं है और मुझे LINQ की जगह SQL लिखने से भी नफरत है। मैं ओआरएम से काफी खुश हूं।

नियोक्ताओं और क्षेत्र के दृष्टिकोण से, क्या एसक्यूएल को जानना महत्वपूर्ण है? क्या मुझे इसमें महारत हासिल करनी है? क्या ऐसी कंपनियां जो ORM फ्रेमवर्क पर शुद्ध SQL पसंद करती हैं, प्रोग्रामिंग दुनिया में "डायनासोर" हैं?

sql orm entity-framework

— किसी को
स्रोत

14

मुझे बुढ़ापा महसूस होता है। एसक्यूएल को बहुत दूर तक सारगर्भित किया गया है कि अब आप इस प्रश्न को गंभीरता से पूछ सकते हैं।

— मार्क

11

@ मर्क: शायद आप गंभीरता से सवाल पूछ सकते हैं, लेकिन जवाब अभी भी वही है।

— एडम रॉबिन्सन

30

अगर मैं कैलकुलेटर का उपयोग कर सकता हूं तो अंकगणित अभी भी महत्वपूर्ण है?

— स्टीवन ए। लोवे

4

SQL Profiler के ज्ञान के बिना NHibernate और JOINs का उपयोग करने के लिए अपने पेट को गुदगुदी करने के लिए, एक प्रदर्शन जिहाद आपके डेटाबेस सर्वर के लिए होने की प्रतीक्षा कर रहा है

— क्रिस एस

2

क्या आपको HTML पता होना चाहिए कि क्या आप ड्रीमविवर का उपयोग कर सकते हैं?

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

63

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

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

पुनरावर्ती और / या पदानुक्रम प्रश्न
वैकल्पिक पैरामीटर (विशेष रूप से उन्हें रेंज में अनुवाद करना भविष्यवाणी करता है)
उपयोगकर्ता-परिभाषित डेटा प्रकार
प्लेटफ़ॉर्म-विशिष्ट प्रकार (SQL पदानुक्रम और TVP, Oracle सरणियाँ और नेस्टेड टेबल, आदि)
बैच आवेषण / अद्यतन / upserts / हटाता है
सूचकांक संकेत
लॉक संकेत (विशेषकर ताले और गंदे रीड्स को अपडेट करें)
गलती संभालना
बाहरी जुड़ाव - उनका परिणाम OOP मॉडल के लिए खराब रूप से सेट होता है, कई ORM की अपनी क्वेरी भाषा होती है, लेकिन यह SQL को जानने के समान है;
संग्रहीत कार्यविधि और यूडीएफ के माध्यम से संशोधन, विशेष रूप से इनलाइन यूडीएफ और क्रॉस एप्लाय प्रश्न
डेटा को कई टेबलों में रखने के लिए OUTPUT / RETURNING का उपयोग
कुशल पेजिंग प्रश्न
विंडो फ़ंक्शंस (पंक्तिबद्धता, रैंक, विभाजन) पर आधारित प्रश्न

सूची आगे बढ़ती है - इनमें से कई चीजें हैं जो एक नौसिखिया डीबीए को कभी नहीं करना पड़ता है, और एक नौसिखिया डेवलपर ने भी कभी नहीं सुना है - लेकिन वे बड़े पैमाने पर ऐप्स में बहुत महत्वपूर्ण हैं।

ORM वास्तव में उबाऊ SQL कोड को तेज करने में बहुत अच्छे हैं - अर्थात, सभी दोहराए गए CRUD और मैपिंग और अन्य प्लंबिंग कोड, इसलिए इनका उपयोग करने में कोई शर्म नहीं है और जो कोई भी व्यक्ति यह कहता है कि वे बुराई करते हैं, उसे मत सुनो। लेकिन आपको निश्चित रूप से सीखने की जरूरत है और हाँ, यहां तक कि मास्टर एसक्यूएल, और कच्चे डीबी कमांड / प्रश्नों को छोड़ने के लिए तैयार रहें, जब ओआरएम अपना वजन नहीं बढ़ा रहा हो।

— Aaronaught
स्रोत

मैं आपके अधिकांश बिंदुओं से सहमत हूं, लेकिन बाहरी जुड़ावों के संबंध में: हां, वे खराब रूप से OOP में मैप करते हैं, लेकिन मुझे लगता है कि OOP समतुल्य (जैसे GroupJoinLINQ में) ज्यादा बेहतर है।

— svick

@ शविक: इसके उपयोग हैं, लेकिन यह एक ही बात नहीं है। एक पूर्ण बाहरी जुड़ाव का अनुकरण करने का प्रयास करें GroupJoin।

— आरोन

हाँ, यह एक ही बात नहीं है। और मुझे लगता है कि आपको जिस समय की सबसे ज्यादा जरूरत है वह वास्तव में ए है GroupJoin। यह सिर्फ यह है कि जो लोग SQL के लिए उपयोग किए जाते हैं, वे तुरंत उन मामलों में शामिल होने के बारे में सोचते हैं और फिर पूछते हैं कि कैसे LINQ में अनुवाद किया जाए। यह सही तरीका नहीं है। आपको अपनी SQL को LINQ में ट्रांसलेट करने की कोशिश नहीं करनी चाहिए, आपको जो भी चाहिए उसका सीधा अनुवाद करना चाहिए।

— svick

@ शविक: टिप के लिए धन्यवाद। रैंक खींचने के लिए नफरत है, लेकिन एक साल के अंतराल के बाद मैं अभी भी स्टैक ओवरफ्लो पर SQL और Linq दोनों के लिए शीर्ष योगदानकर्ताओं में से एक हूं , इसलिए मुझे पूरा यकीन है कि मैं दृष्टिकोण में अंतर को समझता हूं। पूर्ण जोड़ दुर्लभ हैं, लेकिन कभी-कभी वे वास्तव में वही होते हैं जिसकी आपको आवश्यकता होती है और लिनक में बस कोई एनालॉग नहीं है। यह एक ही परिणाम सेट पाने के लिए काफी गन्दा और अक्षम है , इसकी परवाह किए बिना कि यह कैसे संरचित है ।

— आरोन

ऐसा लगता है कि हम वास्तव में सहमत हैं। ज्यादातर मामलों में, आप वास्तव में बाहरी जुड़ाव नहीं चाहते हैं। लेकिन जब आप ऐसा करते हैं, तो इसे LINQ में अनुवाद करना कठिन है।

— svick

90

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

— ओटवियो डेसिओ
स्रोत

6

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

— चिरोन

15

+1 नहीं मुफ्त भोजन! सभी सवालों के साथ मूल रूप से पूछ रहा है कि क्या अज्ञानता ठीक है?

— बेंजो

7

@बेनज़ादो: ऐसा नहीं है कि मुझे लगता है कि यह एसक्यूएल के लिए वारंट है, लेकिन आपको कुछ चीजों के बारे में अज्ञानता का चयन करना होगा; वास्तव में उन सभी को जानने के लिए बहुत सारी तकनीकें हैं (यहां तक कि अच्छे भी!)। तो मुझे लगता है कि यह पूछना ठीक है "अगर मैं वास्तव में अच्छी तरह से वाई जानता हूं या अगर मैं जेड कर रहा हूं तो क्या एक्स अनावश्यक है?"

— क्रेग वॉकर

2

@ क्रेग मैं मानता हूं कि सीखने के लिए बहुत कुछ है, लेकिन एक प्रोग्रामर को वास्तव में नीचे के स्तरों का एक बुनियादी ज्ञान होना चाहिए जहां वह काम कर रहा है।

— बेंज़ादो

2

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

— HLGEM

25

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

— केविन क्लाइन
स्रोत

14

एसक्यूएल कौशल आज आईटी में कौशल होना चाहिए। LINQ एक Microsoft केवल तकनीक है। SQL usages वेब और क्लाइंट / सर्वर एप्लिकेशन डेवलपमेंट से परे जाते हैं। यदि आप SQL के साथ अच्छे नहीं हैं तो आप डेटाबेस को मॉडल नहीं कर सकते हैं और ETL नहीं कर सकते हैं। आपको अपने डेटा वेयरहाउस उत्पादों के लिए ORACLE और SQL सर्वर में प्रयुक्त SQL बोलियों को मास्टर करने की आवश्यकता नहीं हो सकती है, लेकिन आपको मानक SQL पता होना चाहिए। एसक्यूएल मूल बातें सरल हैं, आपको शुरू करने के लिए कई टन सामग्री है।

— कोई मौका नहीं
स्रोत

1

जो कोई भी जानता है कि LINQ कैसे काम करता है वह एक दिन में मूल SQL सीख सकेगा। यह एसक्यूएल सीखने के लिए एक भयानक तर्क है।

— बोरिस यांकोव

6

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

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

— मार्नेन लाईबो-कोसर
स्रोत

जबकि मैं मानता हूं कि SQL जानना बहुत उपयोगी है - मूल रूप से अनिवार्य है - मैं आपके कारणों से असहमत हूं। उस तर्क के साथ आपको किसी भी प्रोग्राम को लिखने से पहले ASM और अपने CPU आर्किटेक्चर को जानना होगा, क्योंकि उच्च स्तरीय भाषाएं चीजों को आसान बनाती हैं, लेकिन वे टूल (अमूर्त चीजों के लिए) हैं, इसलिए यदि आप अपने प्रोसेसर के निर्देशों और आर्किटेक्चर को सीखने से इंकार करते हैं, तो आपके पास कोई व्यवसाय नहीं है एक कंप्यूटर। <--- कोई मतलब नहीं बनाता है। वास्तविक कारण आपको इसकी आवश्यकता है कि ORM उपकरण अभी भी अपनी प्रारंभिक अवस्था में हैं; मुझे आश्चर्य नहीं होगा अगर अब से 5-10 साल SQL ज्ञान की आवश्यकता समाप्त हो जाए

— थॉमस बोनिनी

उच्च-स्तरीय भाषाएं इस तरह से बनाई जाती हैं कि वे आपको अंतर्निहित वास्तुकला के बारे में जानने से रोकती हैं, सच है। यह संभव है क्योंकि डोमेन अंतर्निहित वास्तुकला के साथ सराहनीय है। ORMs, हालांकि, एक अलग मामला है। मैं ORM का बहुत बड़ा प्रशंसक हूं, लेकिन मुझे नहीं लगता कि एक दिन कभी आएगा जब आप SQL (या जो भी अंतर्निहित DB का उपयोग करता है) को जाने बिना उपयोग कर सकते हैं। ऑब्जेक्ट और संबंधपरक मॉडल मौलिक रूप से अक्षम हैं, और मुझे लगता है कि हमेशा ऐसी अवधारणाएं होंगी जो एक से दूसरे में अनुवाद नहीं करती हैं। इसके अलावा, मैं आज के

— ORM के

3

+1: "यदि आप SQL सीखने से इंकार करते हैं, तो आपके पास कोई भी व्यवसाय नहीं है जो SQL डेटाबेस को स्पर्श करता है, या तो ORM के साथ या उसके बिना, और आपको किसी अन्य प्रकार का काम ढूंढना चाहिए।"

— वेक्टर

2

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

— एचएलजीईएम

1

+1 के लिए "उपकरण (आप जानते हैं कि अमूर्त चीजों के लिए), बैसाखी नहीं।"

— शॉलिंजर

4

मैं मानता हूं कि मैं एक कठिन ओआरएम प्रशंसक हूं और वर्षों से ओआरएम के लाभों का प्रचार कर रहा हूं और इस बारे में बहुत कुछ कहना था कि ओआरएम SQL को क्यों रौंदता है।

परंतु...

मुझे स्वीकार करना होगा कि SQL वास्तविक दुनिया में पूरी तरह से और पूरी तरह से आवश्यक है और हर डेवलपर को SQL की अच्छी समझ होनी चाहिए।

SQL प्रोक लगभग सभी मामलों में ORM से तेज़ हैं। यद्यपि आप ज्यादातर मामलों में ओआरएम आउटपुट को आशावादी बना सकते हैं, लेकिन यह एसक्यूएल प्रोक्स के करीब दूसरे स्थान पर आता है।

अवसर पर, आपको अपेक्षित परिणाम प्राप्त करने के लिए कुछ भारी शुल्क एसक्यूएल की आवश्यकता होती है और एसक्यूएल प्रोक्स में बनाने के लिए ये राक्षस प्रश्न आसान और तेज़ होते हैं।

बस मेरे दो बिट्स।

— SetiSeeker
स्रोत

4

एक समय आएगा जब आपको कुछ जटिल का अनुकूलन करना होगा जो ORM बना रहा है। उस बिंदु पर आमतौर पर आपके पास तोड़ने के लिए एक अत्यंत जटिल क्वेरी होती है। यदि आपने मूल बातें कभी नहीं सीखी हैं, तो आप उन्नत सामान के साथ एसक्यूएल सीखना कैसे शुरू कर सकते हैं? तुम भी शुरू करने के लिए पर्याप्त समझ में नहीं आएगा। एक ऐसे व्यक्ति के हाथों में ORMs जो SQL को समझता है - एक अच्छा उपकरण। किसी ऐसे व्यक्ति के हाथों में ORMs जो SQL को बिल्कुल भी नहीं जानता - आपदा होने की प्रतीक्षा कर रहा है।

डेटाबेस को समझने के लिए SQL महत्वपूर्ण क्यों है इसका एक कारण यह है कि एप्लिकेशन प्रोग्रामर डेटा सेट के मामले में स्वाभाविक रूप से नहीं सोचते हैं। लेकिन सभी कुशलता से डेटाबेस संचालित एकमात्र तरीका सेट द्वारा है। आपको यह जानने की आवश्यकता है कि ओआरएम का उपयोग करने का प्रयास करने से पहले आपको सेट में कैसे सोचना चाहिए।

— HLGEM
स्रोत

3

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

— jwenting
स्रोत

3

इससे पहले कि मैं सवाल के बारे में बात करूं, पहले थोड़ा सा परिचय; मुझे ओआरएम पसंद है। और मुझे SQL से नफरत है। मुझे ORM से प्यार है क्योंकि वे SQL-है कि उपयोगकर्ता-अमित्र गड़बड़ को छिपाते हैं, और डेटाबेस से निपटने के लिए एक अच्छा भाषा-एकीकृत तरीका प्रदान करते हैं।

हालाँकि, मैं मानता हूँ कि एसक्यूएल के बहुत सारे लाभ हैं, जिनमें से एक बड़ा सटीक है। मैं एक SQL क्वेरी की जटिलता के बारे में बहुत बहस कर सकता हूं, अंतर्निहित डेटाबेस स्कीमा के विस्तृत ज्ञान के बिना, बस क्वेरी के माध्यम से जाकर। इसलिए, जब मैं SQL का उपयोग करता हूं, तो मैं हमेशा सतर्क रहता हूं, और मुझे हमेशा एक अंतर्ज्ञान होता है कि एक घटक की जटिलता कहां बढ़ रही है।

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

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

— चारलांबोस पास्चलाइड्स
स्रोत

3

मुझे यह भी लगता है कि कभी-कभी (नियमित एसक्यूएल के साथ भी) लोग यह भूल जाते हैं कि सिर्फ एक डेटा सेट वापस करने का मतलब यह नहीं था कि यह सही डेटा सेट था। मुझे लगता है कि यह एक ORM के साथ भूलना आसान हो जाता है जब आप यह मान लेते हैं कि आपने सही काम किया है क्योंकि आप वास्तव में यह नहीं समझते हैं कि यह वैसे भी क्या करता है।

— HLGEM

मैं ORM पर SQL से कम जटिल होने पर असहमत हूं। SQL से आप बिना प्रोग्रामिंग के डाटा को पुनः प्राप्त कर सकते हैं। एसक्यूएल एक प्रोग्रामिंग भाषा नहीं है, बल्कि एक घोषणात्मक है, इसलिए इसमें कोई समय नहीं है, इसके लिए या यदि-तब संरचनाएं।

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

1

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

— चारलांबोस पास्चलाइड्स

2

यदि आपको कभी भी केवल डेटाबेस के साथ इंटरेक्ट करना है, भले ही आप जिस एप्लिकेशन का निर्माण कर रहे हैं, आपको उसकी आवश्यकता नहीं है। कुछ छोटी कंपनियों या डेवलपर टीमों में, आपको कुछ सहायता करनी पड़ सकती है। क्लाइंट के डेटाबेस से कनेक्ट करना और उनके डेटा के साथ क्या हो रहा है, यह देखने के लिए कुछ sql स्टेटमेंट चलाना बहुत आसान है।

— JeffO
स्रोत

जिसे वह निर्माण कर रहा है केवल आवेदन के माध्यम से डेटाबेस के साथ बातचीत करने की आवश्यकता है?

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

2

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

1

इन सभी प्रकार के प्रश्नों का उत्तर ("क्या मुझे एक्स जानने की आवश्यकता है?") "यह सीखें कि आपको पहली बार इसकी आवश्यकता है, यदि आपको कभी इसकी आवश्यकता होगी"।

हालांकि यह महत्वपूर्ण है कि चीजों को कम कुशलता से करने के चक्कर में न पड़ें क्योंकि आप उनके बारे में जानते नहीं हैं या उन्हें करने का कुशल तरीका जानने के इच्छुक नहीं हैं।

इस विशेष मामले में, उदाहरण के लिए, आप क्या करते हैं यदि आपको पता चलता है कि आपके कार्यक्रम में कोई बग था, जिसके कारण PostCountआपकी उपयोगकर्ता तालिका का क्षेत्र कभी-कभी गलत हो सकता है।

आप बग को ठीक करते हैं और अब आपको सभी उपयोगकर्ताओं के लिए PostCount को अपडेट करना होगा। आप इसे कैसे करते हो?

यदि आप ऐसा करने के लिए ORM का उपयोग करके थोड़ी स्क्रिप्ट लिखते हैं तो आप बहुत अक्षम हैं; एक बहुत ही सरल SQL क्वेरी करेगा।

चूंकि ये स्थितियां काफी सामान्य हैं, मुझे डर है कि आप ऊपर वर्णित जाल में गिर गए!

— थॉमस बोनी
स्रोत

2

मैं मानता हूं: यदि आप एसक्यूएल को नहीं जानते हैं, तो आप अक्सर एक एसक्यूएल क्वेरी के साथ जो कर सकते हैं, उसे करने के लिए दर्जनों लाइनें लिखते हैं।

— बेंजो

2

"इसे पहली बार जानें कि आपको इसकी आवश्यकता है": ro-che.info/ccc/11.html

— MatrixFrog

1

हाँ, आपको अभी भी SQL की आवश्यकता है।

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

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

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

— वारंट
स्रोत

0

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

जब हम इस बिंदु पर पहुँचते हैं कि बड़े डेटासेट में हेरफेर करना हाथ से करते समय उदाहरण के लिए 3 एमएस लेता है, और जब आप अमूर्त परत को आपके लिए करते हैं तो 100 एमएस, हर तरह से, एब्स्ट्रेक्शन लेयर को आपके लिए संभालना चाहिए, क्योंकि आप कर सकते हैं 30 गुना धीमा हो, लेकिन आप अभी भी (शायद, अधिकांश अनुप्रयोगों के लिए) तेजी से पर्याप्त हैं। स्थिति की वास्तविकता यह है कि जब आप हाथ से अनुकूलित समाधान देख रहे होते हैं जहां आपके पास 200 एमएस प्रतिक्रिया समय होता है, और जब अमूर्त परत आपके लिए इसे संभालती है, तो एल्गोरिथ्म 'सिर्फ' 10 बार प्रदर्शन हिट लेता है, आपके पास एक है 2 सेकंड की देरी, और फिर आप पूरी देखभाल करते हैं, क्योंकि यह तेजी से नहीं, दर्द से धीमी गति से बढ़ता है। यह देखते हुए कि रिलेशनल डेटाबेस सॉल्यूशंस ठीक नहीं हैं, मुझे नहीं लगता कि यह दो या तीन वर्षों में हल हो जाएगा। इसका मतलब है कि आप अभी भी नंगे धातु के लिए नीचे उतरना होगा जब यह बड़े डेटाबेस के लिए आता है, या आपका आवेदन इतना धीमा होगा, तो यह प्रतियोगियों के लिए खड़ा नहीं हो सकता है।

— Martijn
स्रोत