क्या अभी भी SQL लिखने की आवश्यकता है?

Question

अधिकांश आधुनिक भाषाओं के लिए बहुत सारे ORM टूल के साथ, प्रोग्राम में SQL को लिखने और निष्पादित करने के लिए अभी भी एक उपयोग मामला है, एक भाषा / वातावरण में जो उनका समर्थन करता है? यदि हां तो क्यों?

स्पष्टता के लिए: मैं यह नहीं पूछ रहा हूं कि क्या प्रोग्रामर को एसक्यूएल जानने की जरूरत है, या अगर मुझे अपने डेस्कटॉप पर एक एसक्यूएल टूल होना चाहिए। मैं विशेष रूप से पूछ रहा हूं कि एक ORM के विपरीत मेरे पास कोड (या कॉन्फ़िगरेशन, या जो भी हो) में क्यों हो सकता है ।

Comments

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

— टोनी

संक्षिप्त उत्तर, हाँ।

— गाबा

Answer 1

• प्रक्रियात्मक कोड लिखने की तुलना में आप डेटा को क्वेरी करने के लिए SQL लिखने में अधिक सहज हैं।
• आपका ORM, देखने में सुंदर है, लेकिन कुछ महत्वपूर्ण क्षेत्र में भयानक धीमी SQL उत्पन्न करता है।
• आपको अपने RDBMS द्वारा उजागर की गई कार्यक्षमता का लाभ उठाने की आवश्यकता है जो आपके ORM के माध्यम से उपलब्ध नहीं है / नहीं किया जा सकता है।
• हर बार जब आप टाइप करते हैं SELECT * FROM..., भगवान एक बिल्ली का बच्चा मारता है। और आप बिल्ली के बच्चे से नफरत करते हैं ।
• आप ORM, OOP या एक आधुनिक भाषा का उपयोग नहीं कर रहे हैं।

Comments

सभी अच्छे कारण। क्षमता हालांकि मेरा नंबर एक होगा। कुछ स्थितियों में एक ORM जैसा कि आपने कहा कि SQL उत्पन्न करता है जो हाथ से अनुकूलित और ठीक ट्यून किया जा सकता है।

— क्रिस

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

— माइक एम।

किटी मरो !!

— जेलीफिशट्री

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

— क्रिस्टोफर महान

लीक से हटकर एक तरफ, यहां के लोग यह भूल जाते हैं कि ज्यादातर ORM को सादे एसक्यूएल प्रश्नों पर कई फायदे हैं: पहला और दूसरा स्तर कैश, आलसी लोडिंग (उत्सुक लोडिंग के साथ एन + 1 मुद्दे से बचने के लिए एक विकल्प होने के नाते) और यूनिट में सक्षम होने के कारण डेटा एक्सेस लेयर (इन-मेमोरी डेटाबेस के लिए DBMS स्विच करके), बस कुछ ही नाम रखने के लिए ...

— rsenna

Answer 2

जटिल एसक्यूएल लेखन

ORM बुनियादी चीजों के लिए महान हैं। हालाँकि जटिल परिस्थितियों के लिए आपको एसक्यूएल लिखना होगा।

तो संक्षेप में, वहाँ सबसे निश्चित रूप से SQL की आवश्यकता है और यह हमेशा ऐसा ही रहेगा।

Comments

मैंने हाल ही में एक सह-कार्यकर्ता की परियोजना को फिर से लिखा है। मैंने उनकी 150 सी एसक्यूएल स्क्रिप्ट के साथ 9 सी # प्रोजेक्ट (जिसमें 2 डेटा एक्सेस लेयर शामिल हैं) को बदल दिया। प्रोजेक्ट चलाना (जो SharePoint 2010 की योजनाबद्ध मेटाडेटा सेवा में स्कीमा से डेटा आयात करता है) अब 15. के बजाय 3 मिनट लेता है। SQL संस्करण इतना तेज़ और छोटा है कि यह दूरस्थ रूप से मज़ेदार भी नहीं है।

— चींटी

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

— रिक हेंडरसन

Answer 3

• दृश्य
• ट्रिगर
• प्रतिबन्ध
• पैकेज (SSIS, DTS, आदि)
• कभी भी आपको निष्पादन प्रवाह को ठीक से नियंत्रित करने की आवश्यकता होती है

ORM आपको डेटाबेस बनाने, ट्यून करने या स्वचालित करने में मदद नहीं करता है। यह सिर्फ आपको डेटाबेस के साथ बातचीत करने का एक वैकल्पिक तरीका देता है, जब आप उस सभी सामान को पूरा कर लेते हैं।

Comments

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

— सी।

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

— बिल

Answer 4

ज़रूर:

• आम तौर पर ओआरएम बहुत कुछ अतिक्रमण करता है, लेकिन अंत में आपको पता होना चाहिए कि पर्दे के पीछे क्या होता है। यह प्रदर्शन और मापनीयता के लिए महत्वपूर्ण है। हालाँकि अंदर के अनुप्रयोग में मैं उतना SQL नहीं लिखता, लेकिन मैं मोटे तौर पर जानता हूँ कि SQL या DDL कैसा दिखता है।
• डायरेक्ट SQL अक्सर केवल-पढ़ने के लिए लिखने के लिए अच्छा है। ORM क्वेरी भाषा में इसे तैयार करने के लिए बहुत आसान है और आप परिणाम सेट को सीमित भी कर सकते हैं (उदाहरण के लिए 'से आईडी का चयन करें .....')।
• ORM आपको SQL से बिलकुल भी दूर नहीं रखना चाहिए। मैं DB-क्लाइंट (जैसे mysql- क्लाइंट) पर सीधे तदर्थ प्रश्नों के लिए SQL का उपयोग करता हूं। यह आपको बहुत अच्छा यूनिफ़ॉर्म इंटरफ़ेस और समूहीकरण कार्यक्षमता प्रदान करता है।

Answer 5

ORM हमारे सामान्य संबंधपरक DB कार्यान्वयन और हमारे OO भाषा सुविधाओं के बीच प्रतिबाधा बेमेल के कारण मौजूद हैं। वे केवल एक पुल हैं, फिर भी अधिकांश लोग फ्रिज में लिम्बर्गर पनीर की तरह एसक्यूएल का इलाज करते हैं।

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

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

Answer 6

ORM प्रोग्रामर टूल बॉक्स में एक टूल है। उनके अपने मुद्दे हैं। कुछ उदाहरण निम्न हैं:

• Sql को नियंत्रित नहीं कर सकते
• एन + 1 समस्या से ग्रस्त हैं

Comments

"N + 1 समस्या" क्या है? मैं परिचित नहीं हूँ ...

— RationalGeek

मुझे लगता है कि यह यह है: stackoverflow.com/questions/97197/…

— Ax

यकीन नहीं होता कि मैं सहमत हूं। एक अच्छा ओआरएम आपको आवश्यक होने पर कच्ची एसक्यूएल निष्पादित करने देता है, और एन + 1 मुद्दे आमतौर पर धोखेबाज़ गलतियों (जैसे कि आलसी-लोड किए गए संग्रह पर नेस्टेड छोरों) को आसानी से टाला जा सकता है।

— 23

@richeym: जहां पहली चीजें हैं जो मेरे दिमाग में पॉपप होती हैं। हालांकि दूसरे जवाब में मेरी पीठ है। यह कहा जा रहा है कि एक ORM सिर्फ एक उपकरण है, ऐसे मामले हैं जहां कच्चे sql को प्राथमिकता दी जाती है।

— टोनी

Answer 7

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

मैं यह भी बताना चाहता हूं कि ओआरएम के साथ जटिल रिपोर्टिंग प्रभावी रूप से करना आसान नहीं है। और आगे अगर आप आसान crud सामान में सरल SQL नहीं सीखते हैं, तो आप उस बिंदु पर कैसे पहुंचेंगे जहां आप रिपोर्टिंग के लिए जटिल SQL लिख सकते हैं? मैंने कभी ऐसे एप्लिकेशन में काम नहीं किया है जिसकी रिपोर्टिंग की जरूरत नहीं है और अक्सर काफी जटिल होते हैं।

न ही ORM अधिकांश भाग के लिए BI या ETL प्रक्रियाओं के लिए उपयोगी हैं। न ही वे डेटाबेस व्यवस्थापक प्रश्नों के लिए या ऑडिट टेबल में जानकारी खोजने और डेटाबेस परिवर्तनों के किसी विशेष सेट को पूर्ववत करने के लिए उपयोगी हैं। कई चीजें हैं जो अभी भी सबसे प्रभावी रूप से SQL के साथ की जाती हैं। डेटाबेस से क्वेरी करने वाला एप्लिकेशन एंटरप्राइज़ वातावरण में इसे क्वेरी करने की आवश्यकता का एक छोटा सा हिस्सा है।

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

Answer 8

कभी-कभी एक ग्राहक किसी रिपोर्ट, निर्यात, डेटाडम्प, आदि के लिए डेटा वापस करने के लिए एक त्वरित और आसान क्वेरी चाहता है और पूरे कार्यक्रम के लिए प्रतीक्षा करना चाहता है।

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

इसके अलावा, बहुत समृद्ध और शक्तिशाली प्रक्रिया भाषा के साथ ओरेकल जैसे डेटाबेस का उपयोग करते समय, आप कभी भी "प्रोग्राम" की आवश्यकता के बिना बहुत कुछ कर सकते हैं। दाएं हाथों में Oracle पर PL / SQL बहुत तेज और प्रभावकारी है।

Comments

PL / SLQ का अर्थ "प्रक्रियात्मक भाषा / संरचित क्वेरी भाषा" है, इसलिए यह "कार्यक्रम" कैसे नहीं है?

— क्रिस्टोफर महान

क्रिस्टोफर महान: बिल्कुल। मैंने जिस कंपनी के लिए काम किया है, उसका मुख्य उत्पाद जावा कोड (LOC) की तुलना में ~ 5 गुना अधिक PL / SQL कोड है।

— user281377

Answer 9

यदि आप स्वयं डेटाबेस का उपयोग करना चाहते हैं, तो हाँ। ज्यादातर ओआरएम जिनका मैंने उपयोग करने की कोशिश की, वे पर्याप्त नहीं थे या मैंने अपने डेटाबेस को कवर नहीं किया था। इसके अलावा, आप कैसे कस्टम प्रश्नों का निवारण या लेखन कर रहे हैं जो कवर नहीं किए गए हैं?

Answer 10

यह अभी भी ट्रिगर और संग्रहीत प्रक्रियाओं को लिखने के लिए आवश्यक है। वर्तमान में संग्रहीत प्रक्रियाएँ अनुकूल हो सकती हैं, लेकिन वे अभी भी कुछ स्थितियों में बहुत उपयोगी हैं। SQL को कुछ विशेष रूप से बालों वाली मल्टी-टेबल जॉइन के लिए भी आवश्यक हो सकता है।

Answer 11

हाँ आप SQL लिखने से बच सकते हैं। लेकिन आप इसके बजाय HQL (या Linq, या DQL ...) लिखना समाप्त कर देंगे!

गंभीरता से, मैं ORM का बहुत बड़ा प्रशंसक हूं, और मुझे लगता है कि कोई भी अधिकांश समय शुद्ध SQL का उपयोग करने से बच सकता है। लेकिन हमें याद रखना चाहिए कि एक ORM केवल एक बड़ा अमूर्त है, और सभी बड़े अमूर्त रिसाव ...

(लेकिन एन + 1 समस्या के बारे में: यह आलसी-लोडिंग से संबंधित है, और अधिकांश ओआरएम टूल्स में उत्सुक-लोडिंग का अनुरोध करने का कुछ तरीका है, इस प्रकार उस विशेष मुद्दे से बचा जाता है।)

Answer 12

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

Answer 13

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

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

बाकी समय आपको अपने CRUD सामान के लिए SQL की आवश्यकता नहीं हो सकती है, लेकिन सरल चयन, INSERT, UPDATE और बुनियादी JOIN क्वेरी की तुलना में SQL में बहुत अधिक है। आप इसके साथ बहुत चालाक चीजें कर सकते हैं और यद्यपि आप उन्हें अक्सर उपयोग नहीं कर सकते हैं, यह जानना उपयोगी है कि वे क्या हैं।

तेजी से, मुझे लगता है कि हम खुद को एक पोस्ट SQL दुनिया में पाएंगे, हालांकि- अधिकांश क्लाउड सेवाएं गैर-वर्ग तालिका संग्रहण का उपयोग करती हैं और साधारण CRUD प्रकार के लिए SQL की पूर्ण शक्ति अनावश्यक है। लेकिन इसका मतलब यह नहीं है कि इसे समझने में कोई मूल्य नहीं होगा।

इसके अलावा, निश्चित रूप से, किसी को बेहतर ओआरएम प्रणाली लिखने के लिए पर्याप्त जानना होगा यदि वर्तमान वाले बहुत ऊपर नहीं हैं। यदि वे SQL जानते हैं तो यह उनकी मदद करेगा ...

Comments

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

— क्रिस्टोफर महान

Answer 14

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

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

Comments

"किसी भी बड़े पैमाने पर ऐप को मेमोरी दृढ़ता परत (रैम में) का उपयोग करना चाहिए जो डीबी के मेमोरी कैशिंग भागों में होना चाहिए जो अक्सर उपयोग किए जाते हैं।" - कोई भी सभ्य डेटाबेस ऐसा कर रहा होगा।

— मैथ्यू फ्रेडरिक

Android और iPhoneOS दोनों SQLite, एक SQL-92 आज्ञाकारी डेटाबेस प्रणाली का उपयोग करते हैं। देखें stackoverflow.com/questions/2011724/...

— क्रिस्टोफर महन

Answer 15

जटिलता और एसक्यूएल I की मात्रा उचित में एक ORM ढांचे को हुक करने के लिए पर्याप्त नहीं है।

(मैं प्रति माह एक बार एसक्यूएल लिखता हूं, यदि)

Answer 16

मैं DBA के साथ कई बड़े कोर में आया हूं, जो सक्रिय रूप से ORM टूल का उपयोग कर डरते हैं।

वे डीबीए हैं जो ट्यूनिंग और प्रदर्शन में शामिल हैं।

और हां, ORM टूल को इस तरह से सामान करने में कामयाब किया जा सकता है, लेकिन मैंने ऐसी जगहें देखी हैं जहां वे केवल एक संग्रहीत प्रक्रिया (Sql Server) को स्वीकार करेंगे और आपसे सवाल करेंगे कि आप इसमें क्या कर रहे हैं।

इसके अलावा, ORM टूल्स का बुरी तरह से दुरुपयोग किया जा सकता है और खुद को Sql लिखने के रूप में गरीब Sql के रूप में उत्पादन कर सकते हैं।

Comments

मुझे लगता है कि डीबीए जो एक ओआरएम का उपयोग करने वाले एक देवता की चिंता करता है वह एक देवता के प्रति चिंतित है जो एक विश्लेषक / प्रबंधक / ग्राहक के बारे में चिंता करने वाला एक उपकरण दिया है जो उन्हें कोड लिखने देता है!

— gbjbaanb

Answer 17

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