SQL के लिए प्यार क्यों नहीं? [बन्द है]

116

बंद हो गया । यह सवाल राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

4 साल पहले बंद हुआ ।

इस प्रश्न को सुधारें

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

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

SQL कितना भयानक बनाता है, और क्यों डेटाबेस अमूर्त परतें मूल्यवान हैं?

sql frameworks

— ट्रैविस
स्रोत

11

प्रकार की सुरक्षा के बारे में क्या?

— जॉनी

3

वास्तव में ये अमूर्त परतें किसे लक्षित करती हैं? एसक्यूएल एक ऐसी भाषा नहीं है जो हर किसी का अच्छा है, और इसलिए उन्हें औसत दर्जे के प्रोग्रामर के लिए लक्षित किया जा सकता है। गैर-प्रोग्रामर के लिए SQL स्वयं एक अच्छी भाषा नहीं है।

— डेविड थोरले

27

@ डेविड: एक कंप्यूटर (कंप्यूटर) भाषा को परिभाषित करें जो "गैर-प्रोग्रामर के लिए अच्छा है"। गैर-प्रोग्रामर, IMHO, को प्रोग्रामिंग भाषाओं (और शब्द, SQL के व्यापक अर्थ में) से दूर रहना चाहिए ।

— देवसोलर

15

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

— के.एम.

6

@ केएम: वोटों के साथ समस्या यह है कि वे एक उत्तर पढ़ने वाले लोगों की संख्या पर बहुत अधिक निर्भर करते हैं। मैंने कई NHibernate और राइनो मोक्स सवालों के जवाब दिए जिनका सही उत्तर देने में कुछ समय लगा - और स्वीकार किया गया लेकिन एक भी वोट नहीं मिला। यदि आप C # के बारे में कुछ तुच्छ जवाब देते हैं, तो आपको दर्जनों वोट मिलते हैं। वोट सिर्फ उचित नहीं हैं। यदि आप कुछ बेहतर जानते हैं, तो meta.stckoverflow पर कुछ सुझाव दें।

— स्टीफन स्टाइनगर

132

यह आंशिक रूप से व्यक्तिपरक है। तो यह मेरी राय है:

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

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

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

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

लेकिन यह सच है - कोई संभव विकल्प नहीं हैं। इसलिए हम सभी अगले कुछ वर्षों के लिए SQL का उपयोग करेंगे।

— स्टीफन स्टाइनगर
स्रोत

31

"बस आप क्या चाहते हैं - हम जितनी जल्दी हो सके वितरित करते हैं।" यह घोषणात्मक दृष्टिकोण शानदार है, और यह वास्तव में आधुनिक है (LINQ सोचो)। यह सच है कि कभी-कभी आपको गति के लिए ट्विक करने की आवश्यकता होती है, और SQL का एक प्रक्रियात्मक विकल्प तब उपयोगी हो सकता है। लेकिन मैं अभी भी सादगी के लिए ज्यादातर समय घोषणात्मक एसक्यूएल का उपयोग कर रहा हूं।

— MarkJ

4

MarkJ: मुझे याद है कि मैंने oracle में प्रश्नों को ऑप्टिमाइज़ करने के लिए WHaus क्लोज़ किया था। वे जहां नीचे से ऊपर तक हल करते थे ... भयानक।

— स्टीफन स्टाइनगर

16

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

— Jay

12

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

— क्लूज

5

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

— क्रुचचन

58

इसके अलावा जो कुछ कहा गया था, एक तकनीक को अमूर्त परत को मूल्यवान बनाने के लिए बुरा नहीं होना चाहिए ।

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

एसक्यूएल महान है। इस पर अमूर्त परतें इसे और भी बड़ा बनाती हैं!

— मिगुएल वेंचुरा
स्रोत

6

बहुत कूटनीतिक! (और सच, बूट करने के लिए!)

— जोसेफ फेरिस

2

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

— स्टीवन हुआविग

2

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

— Dereleased

53

अमूर्त परतों का एक बिंदु यह तथ्य है कि एसक्यूएल कार्यान्वयन एक-दूसरे के साथ कम या ज्यादा असंगत होते हैं क्योंकि मानक थोड़ा अस्पष्ट है, और यह भी क्योंकि अधिकांश विक्रेताओं ने अपने स्वयं के (गैर-मानक) एक्स्ट्रा जोड़ दिए हैं। यह है कि, SQL एक MySQL DB के लिए लिखा है, के साथ काफी समान रूप से काम नहीं कर सकते हैं, कहते हैं, एक Oracle DB - भले ही यह "चाहिए"।

मैं सहमत हूँ, हालांकि, कि एसक्यूएल वहाँ से बाहर अमूर्त परतों की तुलना में बेहतर है। यह SQL की गलती नहीं है कि यह उन चीजों के लिए उपयोग किया जा रहा है जिन्हें इसके लिए डिज़ाइन नहीं किया गया था।

— जूनस पुलका
स्रोत

19

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

— जेफ मीटबॉल यांग

7

यह एसक्यूएल के खिलाफ एक बिंदु नहीं है, यह अमूर्त परतों के लिए एक बिंदु है । जैसे, आप बस कहीं भी एक ही सी कोड को + संकलित नहीं कर सकते, यह अधिक मंच उदासीन भाषाओं के लिए एक बिंदु है । लेकिन यह SQL और C को "बकवास" नहीं बनाता है: अमूर्त परतें वैसे भी गहरी परतों के ऊपर चलती हैं।

— जूनास पुलका

8

@ जेफ़: सी में, सामान्य कार्य मानक का हिस्सा हैं। SQL में, विक्रेता विशिष्ट SQL में शामिल हुए बिना किसी परिणाम को सेट करना असंभव है।

— पॉवरलॉर्ड

4

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

— जूनास पुलका

3

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

— जेफ मीटबॉल यांग

36

SQL कई स्रोतों से खराब हो जाता है:

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

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

SQL की आलोचना अक्सर RDBMSes की आलोचना के लिए एक स्टैंडिन है। RDBMSes के आलोचकों को यह समझ में नहीं आता है कि वे कंप्यूटिंग समस्याओं के एक बड़े वर्ग को अच्छी तरह से हल करते हैं, और वे यहां हमारे जीवन को आसान बनाने के लिए हैं, कठिन नहीं।

यदि वे SQL की आलोचना करने के बारे में गंभीर थे, तो वे Tutorial D और Dataphor जैसे प्रयासों को वापस कर देंगे।

— स्टीवन हुआविग
स्रोत

7

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

— ट्रेवर टिपिन्स

मुझे स्पष्ट करना चाहिए कि मेरा मतलब था "उन प्रोग्रामर कुछ भी नहीं लेकिन अनिवार्य प्रोग्रामिंग के साथ सहज नहीं हैं," ऐसा नहीं है कि सभी प्रोग्रामर इसके साथ असहज हैं।

— स्टीवन हुआविग

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

— क्रूचन

मुसीबत यह है कि कई बाध्यकारी प्रोग्रामर हैं, जो एक या दो घंटे के लिए चीजों के बारे में सोचने के बजाय अनिच्छुक कोड की कुछ सौ पंक्तियों को बाहर कर देंगे।

— स्टीवन हुआविग

कोड की कुछ पंक्तियों को लिखने या समझने के लिए आपको एक घंटे के लिए चीजों के बारे में नहीं सोचना चाहिए। अवधि।

— एंड्रयू

23

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

— ट्रेवर टिपिन्स
स्रोत

16

SQL प्रबंधन और SET आधारित डेटा की क्वेरी के लिए डिज़ाइन किया गया है। इसका उपयोग अक्सर अधिक करने के लिए किया जाता है और किनारे के मामलों में कई बार निराशा पैदा होती है।

SQL का वास्तविक उपयोग आधार डेटाबेस डिज़ाइन द्वारा SO को प्रभावित किया जा सकता है कि SQL समस्या नहीं हो सकता है, लेकिन डिज़ाइन हो सकता है - और जब आप खराब डिज़ाइन से संबंधित विरासत कोड में टॉस करते हैं, तो परिवर्तन अधिक प्रभावकारी होते हैं और इसका अर्थ महंगा होता है ( कोई भी वापस जाना पसंद नहीं करता है और "फिक्स" सामान जो "काम कर रहा है" और उद्देश्यों को पूरा कर रहा है)

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

— मार्क शुल्त्स
स्रोत

11

मैं नहीं कहता कि यह भयानक है। यह कुछ कार्यों के लिए अनुपयुक्त है। उदाहरण के लिए: आप SQL के साथ अच्छा प्रक्रियात्मक कोड नहीं लिख सकते हैं। मुझे एक बार एसक्यूएल के साथ सेट हेरफेर के साथ काम करने के लिए मजबूर किया गया था। यह पता लगाने के लिए मुझे पूरा सप्ताहांत लगा।

SQL को रिलेशनल बीजगणित के लिए डिज़ाइन किया गया था - यही वह जगह है जहाँ इसका उपयोग किया जाना चाहिए।

— निकोले आर
स्रोत

2

दुर्भाग्यपूर्ण बात यह है कि बस कुछ सरल प्रक्रियात्मक कोड को संग्रहीत प्रक्रिया में रखने के लिए यह बहुत लुभावना है। और यह ठीक काम करता है। UNTIL किसी को इसे बनाए रखने की आवश्यकता है / कुछ अपवादों को जोड़ने, आदि ...

— ब्रायन नोब्लुच

5

-1, जब तक कि यह बिंदु ठीक नहीं है, तब तक SQL को सेट-आधारित होने के लिए डिज़ाइन किया गया है और इसकी शक्ति है। प्रक्रियात्मक शब्दों में सोचने का मतलब है कि आप गलत सोच रहे हैं।

— Cruachan

1

यह पेचकस चूसता है! इसके साथ नाखूनों में धमाका करना कितना कठिन है।

— केसी रोडमोर

9

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

ध्यान दें कि ये परतें सिर्फ अपने सामान को रूपांतरित करती हैं SQL। अधिकांश डेटाबेस विक्रेताओं SQLके लिए इंजन के साथ संवाद करने का एकमात्र तरीका है।

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

... जिस कारण से मैंने अभी ऊपर वर्णित किया है।

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

परिभाषा के अनुसार, डेटाबेस परतों में ऐसा कुछ भी नहीं है जो अंदर नहीं है SQL।

क्या SQLइतना भयानक है, और क्यों डेटाबेस अमूर्त परतों मूल्यवान हैं?

SQL एक अच्छी भाषा है, हालांकि, इसके साथ काम करने के लिए कुछ मस्तिष्क मोड़ लेता है।

सिद्धांत रूप में, SQLघोषणात्मक है, कि क्या आप घोषणा करते हैं कि आप क्या प्राप्त करना चाहते हैं और इंजन इसे सबसे तेज़ तरीके से प्रदान करता है।

व्यवहार में, एक सही क्वेरी तैयार करने के कई तरीके हैं (यह प्रश्न है जो सही परिणाम लौटाता है)।

ऑप्टिमाइज़र कुछ पूर्वनिर्धारित एल्गोरिदम से बाहर लेगो महल बनाने में सक्षम हैं (हाँ, वे कई हैं), लेकिन वे सिर्फ नए एल्गोरिदम नहीं बना सकते हैं। यह अभी भी SQLउनकी सहायता के लिए एक डेवलपर लेता है।

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

और जैसा कि हम सभी जानते हैं, जब कंप्यूटर प्रोग्राम लोगों की अपेक्षाओं पर खरा नहीं उतरता है, तो यह प्रोग्राम ही है, जो उम्मीदों पर खरा उतरता है।

ज्यादातर मामलों में, हालांकि, क्वेरी में सुधार करना वास्तव में सबसे अच्छी योजना का उत्पादन कर सकता है। जब असंभव हो तो ऐसे कार्य होते हैं, हालांकि, SQLइन मामलों में नए और बढ़ते सुधार के साथ संख्या में कम और कम हो जाता है।

यह अच्छा होगा, हालांकि, अगर विक्रेताओं ने "इंडेक्स रेंज प्राप्त करें" जैसे फ़ंक्शन के लिए कुछ निम्न-स्तरीय पहुंच प्रदान की है, तो rowid"आदि द्वारा एक पंक्ति प्राप्त करें " जैसे Cकंपाइलर आपको असेंबली को भाषा में सही एम्बेड करने देते हैं।

मैंने हाल ही में अपने ब्लॉग में इस पर एक लेख लिखा है:

एसक्यूएल में दोहरी सोच

— Quassnoi
स्रोत

7

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

मैं एसक्यूएल को एक सुपर-कुशल भाषा के रूप में देखता हूं जिसमें कोड पुन: उपयोग या रखरखाव / प्राथमिकताओं के रूप में रीफैक्टरिंग नहीं है।

इसलिए बिजली की तेजी से प्रसंस्करण प्राथमिकता है। और यह स्वीकार्य है। आपको बस ट्रेड-ऑफ के बारे में पता होना चाहिए, जो मेरे लिए काफी हैं।

एक सौंदर्य की दृष्टि से, एक भाषा के रूप में मुझे लगता है कि इसमें कुछ चीजों की कमी है क्योंकि इसमें OO अवधारणाएं नहीं हैं और इसी तरह - यह मुझे बहुत पुराने स्कूल प्रक्रियात्मक कोड जैसा लगता है। लेकिन यह कुछ चीजों को करने के लिए सबसे तेज़ और दूर का रास्ता है, और यह एक शक्तिशाली जगह है!

— ब्रायन मैकके
स्रोत

7

मैं कहूंगा कि एक फ्रेमवर्क के साथ शामिल एक डेटाबेस एब्स्ट्रक्शन लेयर एक अच्छी बात है क्योंकि यह दो बहुत महत्वपूर्ण समस्याओं को हल करती है:

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

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

— Dereleased
स्रोत

6

एसक्यूएल कुछ प्रकार के कार्यों के लिए उत्कृष्ट है, विशेष रूप से डेटा के सेट में हेरफेर और पुनर्प्राप्त करना।

हालाँकि, SQL गायब है (या केवल आंशिक रूप से लागू) परिवर्तन और जटिलता के प्रबंधन के लिए कई महत्वपूर्ण उपकरण:

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

अंत में, SQL में CRUD संचालन को मैन्युअल रूप से कोडित करना (और इसे किसी के आवेदन को हुक करने के लिए कोड लिखना) दोहराव और त्रुटि-प्रवण है।

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

— जेफ सनातन
स्रोत

दृश्यता नियंत्रण के लिए स्कीमा के बारे में क्या?

— तीन मान तर्क

5

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

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

— पीटर बेली
स्रोत

5

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

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

— थॉमस
स्रोत

4

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

— tvanfosson
स्रोत

2

सच है, लेकिन आपको इसके लिए

— ओआरएम की

2

पैराड्राइज्ड प्रश्नों का उपयोग करना SQL को सीधे लिखते समय तुच्छ है, बशर्ते आपके पास एक सभ्य डेटाबेस इंटरफ़ेस लेयर हो (जैसे, वह जो प्लेसहोल्डर का समर्थन करता है)। $dbh->do("DELETE FROM my_table WHERE some_value = ?", undef, $target_value); वहाँ। किया हुआ।

— डेव शेरोमैन

मैंने कभी नहीं कहा कि आप रॉ एसक्यूएल के साथ पैरामीटरयुक्त प्रश्न नहीं लिख सकते। मैंने कहा कि कच्ची एसक्यूएल का उपयोग करना जोखिम भरा है क्योंकि आपको इसे स्वयं लागू करना होगा। मैंने कच्चे SQL कोड के कई मामले देखे हैं जहाँ क्वेरी को पैरामीटर नहीं किया गया है। ORM इस लाभ को स्वतः प्रदान करते हैं।

— tvanfosson

2

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

— जे।

3

जे, क्या वह "सरल फ़ंक्शन जो एक स्ट्रिंग के चारों ओर उद्धरण डालता है और सर्वर पर उपयोग में निर्धारित वर्तमान चरित्र को ध्यान में रखता है" किसी भी एम्बेडेड उद्धरण से ठीक से बच जाता है?

— ygrek

4

बहुत हाल ही में सुना? मुझे आशा है कि आप NoSql आंदोलन के साथ इसे भ्रमित नहीं कर रहे हैं। जहाँ तक मुझे पता है कि मुख्य रूप से ऐसे लोगों का एक समूह है जो उच्च स्केलेबिलिटी वेब ऐप के लिए NoSql का उपयोग करते हैं और यह भूल गए हैं कि SQL एक "उच्च स्केलेबिलिटी वेब ऐप" परिदृश्य में एक प्रभावी उपकरण है।

अमूर्त परत व्यवसाय बस ऑब्जेक्ट ओरिएंटेड कोड और टेबल - सेट आधारित कोड के बीच अंतर को सुलझाने के बारे में है जैसे कि एसक्यूएल बात करना पसंद करता है। आमतौर पर यह दोनों के बीच बहुत सारे बॉयलर प्लेट और सुस्त संक्रमण कोड लिखने के परिणामस्वरूप होता है। ओआरएम इसे स्वचालित करता है और इस प्रकार व्यापारिक वस्तु के लोगों के लिए समय बचाता है।

— Quibblesome
स्रोत

4

अनुभवी SQL प्रोग्रामर के लिए बुरे पक्ष हैं

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

दूसरों के लिए, इसके कारण हैं

कुछ प्रोग्रामर SQL में खराब हैं। संभवतः क्योंकि SQL सेट के साथ काम करता है, जबकि प्रोग्रामिंग लैंग्वेज ऑब्जेक्ट या फंक्शनल प्रतिमान में काम करते हैं। सेट्स (यूनियन, प्रोडक्ट, इंटरसेक्ट) में सोचना हाबी की बात है जो कुछ लोगों के पास नहीं है।
कुछ ऑपरेशन स्व-व्याख्यात्मक नहीं हैं: अर्थात पहले यह स्पष्ट नहीं है कि कहां और अलग-अलग सेटों को फ़िल्टर करना है।
बहुत सारी बोलियाँ हैं

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

[26.06.10 को अपडेट करें] हाल ही में मैंने Django ORM मॉड्यूल के साथ काम किया । यह एकमात्र योग्य SQL फ्रेमवर्क है जिसे मैंने देखा है। और यह एक बहुत कुछ के साथ काम कर बनाता है। जटिल समुच्चय हालांकि थोड़ा कठिन हैं।

— culebrón
स्रोत

3

SQL एक भयानक भाषा नहीं है, यह कभी-कभी दूसरों के साथ बहुत अच्छा नहीं खेलता है।

यदि उदाहरण के लिए यदि आपके पास एक ऐसी प्रणाली है जो सभी संस्थाओं को कुछ ओओ भाषा या किसी अन्य में ऑब्जेक्ट के रूप में प्रस्तुत करना चाहती है, तो इसे एसक्यूएल के साथ संयोजन के बिना किसी भी प्रकार की अमूर्त परत के बजाय बोझिल हो सकता है। OO- दुनिया पर एक जटिल SQL क्वेरी को मैप करने का कोई आसान तरीका नहीं है। उन दुनियाओं के बीच तनाव को कम करने के लिए अमूर्तता की अतिरिक्त परतें डाली जाती हैं (उदाहरण के लिए OR-Mapper)।

— जोआचिम सौअर
स्रोत

यह SQL की गलती क्यों है कि OO भाषाएँ इसे अच्छी तरह से मैप नहीं करती हैं? जब आप किसी सेवा का उपयोग करते हैं, तो उसके इंटरफ़ेस के अनुरूप होते हैं या उसका उपयोग नहीं करते हैं।

— के.एम.

2

किसी ने कहा कि यह SQLs गलती है। DB-access का लिंगुआ फ्रैंक एसक्यूएल है। व्यापार तर्क का लिंगुआ फ़्रैंक एक OO- आधारित है। वे दोनों कुछ मदद के बिना पूरी तरह से मेल नहीं खाते। यहां कोई "गलती" या "समस्या" नहीं है, बस कुछ आवश्यकताएं ("उन्हें मेल करें") और एक व्यापक रूप से स्वीकृत समाधान ("ओआर-मैपर का उपयोग करें")।

— जोआचिम सॉर

जोआचिम सॉर ने कहा कि एसक्यूएल एक भयानक भाषा नहीं है, यह सिर्फ दूसरों के साथ बहुत अच्छा नहीं खेलता है मेरे लिए, ऐसा लगता है जैसे किसी ने कहा है

— केएम।

1

@ केएम: क्या आप कह रहे हैं कि फ्रांसीसी और जर्मन बुरी भाषा हैं? वे अंग्रेजी के साथ वह सब नहीं खेलते हैं।

— डेविड थॉर्नले

3

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

SQL से नफरत करने का दूसरा कारण है, रिलेशनल डेटाबेस के कारण।

कैप प्रमेय लोकप्रिय हो जाता है:

साझा-डेटा सिस्टम से आप क्या लक्ष्य प्राप्त कर सकते हैं?

मजबूत संगतता: सभी ग्राहक अपडेट की उपस्थिति में भी समान दृश्य देखते हैं

उच्च उपलब्धता: सभी क्लाइंट डेटा की कुछ प्रतिकृति पा सकते हैं, यहां तक कि विफलताओं की उपस्थिति में भी

विभाजन-सहिष्णुता: सिस्टम के विभाजन के समय भी सिस्टम गुण धारण करते हैं

प्रमेय बताता है कि आपके पास हमेशा एक ही समय में तीन में से दो कैप गुण हो सकते हैं

संबंधपरक डेटाबेस पते मजबूत संगतता और विभाजन-सहिष्णुता।

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

यदि रिलेशनल डेटाबेस खारिज कर दिया जाता है, तो SQL भी अस्वीकार कर दिया जाता है।

— निकोलस डोरिएर
स्रोत

3

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

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

और नल की हैंडलिंग मुझे पागल कर देती है! हां, सैद्धांतिक रूप से यह बहुत अच्छा लग रहा होगा जब किसी ने कहा, "अरे, यदि अशक्त का अर्थ अज्ञात है, तो एक ज्ञात मूल्य में एक अज्ञात मूल्य को जोड़ना एक अज्ञात मूल्य देना चाहिए। आखिरकार, हमें पता नहीं है कि अज्ञात मूल्य क्या है। । " सैद्धांतिक रूप से, बिल्कुल सच। व्यवहार में, यदि हमारे पास 10,000 ग्राहक हैं और हम ठीक से जानते हैं कि 9,999 का कितना पैसा हमारे पास है, लेकिन पिछले एक के द्वारा बकाया राशि के बारे में कुछ सवाल है, और प्रबंधन कहता है, "हमारे कुल खाते प्राप्य हैं?", हाँ, गणित सही है? जवाब है "मुझे नहीं पता"। लेकिन व्यावहारिक उत्तर "हम $ 4,327,287.42 की गणना करते हैं, लेकिन एक खाता प्रश्न में है, ताकि संख्या सटीक न हो"। मुझे यकीन है कि प्रबंधन बहुत करीब होगा, अगर एक खाली ताक की तुलना में निश्चित संख्या नहीं।

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

— नीलकंठ
स्रोत

3

संपूर्ण संबंधपरक डेटाबेस आइडिया आइवरी टावर ब्लू-स्कायर्स का उत्पाद था। प्रारंभिक संबंधपरक डेटाबेस में तत्कालीन पदानुक्रमित डेटाबेस की तुलना में भयानक प्रदर्शन था, और स्थापित होने में लंबा समय लगा। अमूर्तता की शक्ति ऐसी थी कि पदानुक्रमित डेटाबेस अनिवार्य रूप से अतीत की बात है (ऐसा नहीं है कि वहाँ IMS और CODASYL डेटाबेस अभी भी नहीं हैं)। इसे बहुत, बहुत अच्छी तरह से काम करना पड़ा।

— डेविड थॉर्नले

1

लेकिन प्रबंधन "एक निश्चित संख्या के करीब नहीं" नहीं देखेगा - उन्हें एक गलत संख्या दिखाई देगी। हो सकता है कि अंतिम ग्राहक के पास बहुत पैसा हो। तब प्रबंधन उस गलत संख्या के बारे में बहुत दुखी होगा।

— HTTP 410

रोडवर्यर: हाँ, यह संभव है कि आपके पास 10,000 ग्राहक हों, जो प्रत्येक पर आपका 10 डॉलर और 1 ग्राहक का बकाया हो जो आपके ऊपर $ 10 मिलियन बकाया हो। लेकिन अगर ऐसा होता, तो AR रिपोर्ट का अनुरोध करने वाला कोई भी व्यक्ति उस ग्राहक का नाम बहुत अच्छी तरह से जानता होगा और यह जान सकता है कि उनके साथ क्या हो रहा था। ठीक है, मुझे यकीन है कि ऐसे समय होते हैं जब कोई भी उत्तर किसी ऐसे उत्तर से बेहतर नहीं होता है जो इतना अविश्वसनीय हो जितना अर्थहीन हो। लेकिन यह मेरी बात है: एसक्यूएल सैद्धांतिक विचारों के आसपास इस तरह से डिज़ाइन किया गया है: एक हठधर्मिता "पूर्णता से कम कुछ भी बेकार है"। ...

— जे।

... वास्तविक जीवन में, समय का 95%, एक अनुमानित उत्तर एक खाली ताक की तुलना में बेहतर है। जब मैं अपनी चेकबुक को देखता हूं, तो मुझे पता है कि यह काफी संभव है कि मैंने एक अंकगणितीय त्रुटि की है या चेक में लिखना भूल गया हूं। संतुलन अच्छी तरह से एक सन्निकटन हो सकता है। लेकिन फिर भी, अगर मुझे पता है कि मेरे पास "$ 1,000 के बारे में" है, तो मेरे पास $ 50 के लिए चेक लिखने के बारे में कोई योग्यता नहीं होगी, और मुझे एहसास होगा कि $ 10,000 के लिए चेक लिखना निरर्थक होगा।

— जय

खैर, मैंने एक व्यवसाय चलाया है, और यह कभी भी 10K बनाम 1. IMX नहीं है, यह प्रत्येक 100 ज्ञात (पारेतो सिद्धांत) के लिए 20 अज्ञात के समान अधिक है। और उन 20 में से कुछ ने हमें बहुत पैसा दिया, जो वास्तव में वास्तविक राशि विवाद में था। फिर से, यह पेरेटो सिद्धांत है।

— HTTP 410

3

• प्रत्येक विक्रेता अपनी आवश्यकताओं के अनुरूप SQL सिंटैक्स का विस्तार करता है। इसलिए जब तक आप काफी सरल चीजें नहीं कर रहे हैं, आपका SQL कोड पोर्टेबल नहीं है।

• SQL का सिंटैक्स ऑर्थोगोनल नहीं है; उदाहरण के लिए, select, insert, update,और deleteबयानों में पूरी तरह से अलग-अलग वाक्य रचना है।

— डेविड आर ट्रिब्बल
स्रोत

1

यह कैसे वाक्य रचना को रूढ़िवादी नहीं बनाता है?

— अमोक

1

भाषा को डिजाइन किया जा सकता था ताकि इन सभी अनिवार्य कथनों में एक अधिक सामान्य वाक्यविन्यास हो, विशेष रूप से insertऔर updateसंचालन के बीच , जो लगभग समान रूप से, लेकिन पूरी तरह से अलग-अलग रूप से भिन्न हैं।

— डेविड आर ट्रिब्बल

2

मैं आपकी बातों से सहमत हूं, लेकिन आपके प्रश्न का उत्तर देने के लिए, एक चीज़ जो SQL को इतना "भयानक" बनाती है, वह डेटाबेस विक्रेताओं (Sql Server, Oracle आदि) के बीच T-SQL के पूर्ण मानकीकरण की कमी है, जो SQL कोड के होने की संभावना नहीं है। पूरी तरह से पोर्टेबल। डेटाबेस अमूर्त परतें इस समस्या को हल करती हैं, यद्यपि एक प्रदर्शन लागत (कभी-कभी बहुत गंभीर)।

— MusiGenesis
स्रोत

2

मुझे समझ में नहीं आया कि SQL के खिलाफ SQL बोली असंगतताएं इतनी बड़ी "बिंदु" कैसे हो सकती हैं। यह कहना C की तरह बकवास है क्योंकि आप लिनक्स डिस्ट्रोस को अलग करने के लिए एक ही स्रोत को संकलित नहीं कर सकते।

— जेफ मीटबॉल यांग

1

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

— मुसुइनेसिस

1

यह सच है - मैं अमूर्त परतों का भी उपयोग करता हूं - मुझे लगता है कि मेरा कहने का मतलब है कि, मेरे लिए, SQL भाषा समस्या नहीं है - यह वस्तुओं में सामान्यीकृत डेटा का परिवर्तन है, यही कारण है कि अमूर्त परतें उपयोगी हैं।

— जेफ मीटबॉल यांग

2

शुद्ध एसक्यूएल के साथ रहना वास्तव में एक रखरखाव नरक हो सकता है। मेरे लिए ओआरएम का सबसे बड़ा लाभ थकाऊ "डीबी रिफैक्टरिंग" प्रक्रियाओं के बिना सुरक्षित रूप से रिफलेक्टर कोड की क्षमता है। OO भाषाओं के लिए अच्छी यूनिट टेस्टिंग फ्रेमवर्क और रीफैक्टरिंग टूल हैं, लेकिन मुझे अभी तक SQL के लिए Resharper का प्रतिरूप देखना है, उदाहरण के लिए।

अभी भी सभी DALs में पर्दे के पीछे SQL है, और फिर भी आपको यह समझने की आवश्यकता है कि आपके डेटाबेस में क्या हो रहा है, लेकिन दैनिक अच्छा अमूर्त परत के साथ काम करना आसान हो जाता है।

— ovolko
स्रोत

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

— के.एम.

2

यदि आपने SQL का बहुत अधिक उपयोग नहीं किया है, तो मुझे लगता है कि प्रमुख समस्या अच्छे डेवलपर टूल की कमी है।

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

— जेफ मीटबॉल यांग
स्रोत

2

त्वरित, मुझे MySQL, Oracle, MSSQL, PostgreSQL और DB2 में काम करने वाले डेटासेट को paginate करने के लिए SQL लिखें।

ओह, ठीक है, मानक SQL वापस आने वाले परिणामों की संख्या और किस पंक्ति को शुरू करने के लिए सीमित करने के लिए किसी भी ऑपरेटर को परिभाषित नहीं करता है।

— Powerlord
स्रोत

5

आप अपने कोड के साथ उन सभी वातावरणों को लक्षित करने का प्रयास क्यों कर रहे हैं? Mac OS 9, Windows NT, OS / 2 Warp और Solaris में काम आने वाले थ्रेड्स के लिए C कोड लिखें।

— स्टीवन ह्विग

2

@Steven Huwig: मैं शायद मेरे लिए इसे करने के लिए एक अमूर्त परत का उपयोग करूँगा ... जो कि वास्तव में सवाल पूछ रहा था।

— पॉवरलॉर्ड

@Steven: मैं उन कुछ चीजों के लिए चौखटे और अमूर्त परतों का उपयोग करने के लिए होता हूँ जहाँ मुझे स्वतंत्र होने की आवश्यकता होती है। हालाँकि, डेटाबेस की स्वतंत्रता होना ज्यादातर मामलों में बहुत अधिक महत्वपूर्ण है। यहां तक कि अगर आप केवल अपने सॉफ़्टवेयर को विंडोज पर चलाने के लिए वितरित कर रहे हैं, तो एक बार जब आप इसे बड़े निगमों को बेचते हैं, तो आप "हम पसंद करते हैं ओएसएस, क्या आप MySQL का समर्थन करते हैं" से "हम Oracle का उपयोग करते हैं" MSSQL | एक कॉर्पोरेट मानक, क्या आप इसका समर्थन करते हैं "।

— फ्रेड्रिक

2

SQL के लिए कोई प्यार नहीं है क्योंकि SQL सिंटैक्स, शब्दार्थ और वर्तमान उपयोग में खराब है। मैं समझाऊंगा:

यह वाक्य रचना एक कोबोल छर्रे है, सभी कोबोल आलोचना यहां (कुछ हद तक, निष्पक्ष होने के लिए) लागू होती है। वास्तव में प्राकृतिक भाषा के रूप में प्राकृतिक भाषा की व्याख्या करने की कोशिश किए बिना प्राकृतिक रूप से वाक्यविन्यास बनाने की कोशिश की जाती है (क्या यह DROP TABLE या DROP, UPDATE TABLE, UPDATE या UPDATE IN, DELETE या DELETE FROM है ...) और सिंटैक्टिकल मोनस्ट्रोसिटीज़ जैसे SELECT (कितने पृष्ठ करता है) इसे भरें;)
शब्दार्थ भी गहराई से त्रुटिपूर्ण है, तिथि इसे बहुत विस्तार से बताती है, लेकिन यह ध्यान रखना पर्याप्त होगा कि तीन मूल्यवान बूलियन तर्क वास्तव में एक संबंधपरक बीजगणित में फिट नहीं होते हैं जहां एक पंक्ति केवल तालिका का हिस्सा हो सकती है या नहीं हो सकती है।
डेटाबेस के लिए एक प्रोग्रामिंग भाषा मुख्य (और अक्सर केवल) के रूप में होने से वास्तव में एक बुरा विकल्प साबित हुआ और इसने सुरक्षा की एक नई श्रेणी बनाई

— stupito
स्रोत

1

मैं यहाँ अधिकांश पोस्टों से सहमत हूँ कि SQL की उपयोगिता पर बहस ज्यादातर व्यक्तिपरक है, लेकिन मुझे लगता है कि यह आपके व्यवसाय की आवश्यकताओं की प्रकृति में अधिक व्यक्तिपरक है।

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

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

SQL के साथ मेरे पास सबसे बड़ी समस्या अन्य "मानकीकृत" भाषाओं की तरह है, बहुत कम वास्तविक मानक हैं। मैं लगभग पूरी तरह से Sybase और MySQL के बीच एक नई भाषा सीखने के लिए प्राथमिकता देता हूं ताकि मुझे दो सम्मेलन भ्रमित न हों।

— NateDSaint
स्रोत

आप सिर्फ MySQL का उपयोग न करके अपने आप को उस दर्द से काफी हद तक बचा सकते हैं। ;)

— स्टीवन हुआविग

1

जबकि एसक्यूएल काम करता है यह निश्चित रूप से मुद्दों है ...

यह एक साथ उच्च स्तर और निम्न स्तर अमूर्त होने का प्रयास करता है, और उस के ... अजीब। शायद यह विभिन्न स्तरों पर दो या अधिक मानक होने चाहिए थे।
यह एक मानक के रूप में एक बड़ी विफलता है । बहुत सी चीजें गलत हो जाती हैं जब एक मानक या तो सब कुछ में स्थिर हो जाता है, बहुत अधिक कार्यान्वयन पूछता है, बहुत कम पूछता है, या किसी कारण से विक्रेताओं और कार्यान्वयनकर्ताओं को प्रेरित करने के आंशिक रूप से सामाजिक लक्ष्य को पूरा नहीं करता है, जिससे कि पूर्णतः अंतःक्रियात्मक पूर्ण कार्यान्वयन हो। आप निश्चित रूप से यह नहीं कह सकते हैं कि एसक्यूएल ने ऐसा किया है। कुछ अन्य मानकों को देखें और ध्यान दें कि मानक की सफलता या विफलता स्पष्ट रूप से प्राप्त उपयोगी सहयोग का कारक है:
- RS-232 ( बुरा , लगभग पर्याप्त निर्दिष्ट नहीं है, यहां तक कि जो पिन संचारित करता है और जो पिन प्राप्त करता है वह वैकल्पिक है, शीश। आप अनुपालन कर सकते हैं लेकिन फिर भी कुछ भी प्राप्त नहीं कर सकते हैं। सफल इंटरॉप की संभावना: वास्तव में कम जब तक आईबीएम पीसी ने डी-फैक्टो उपयोगी मानक नहीं बनाया ।)
- आईईईई 754-1985 फ्लोटिंग पॉइंट ( खराब , ओवररेच : एक भी सुपर कंप्यूटर या वैज्ञानिक कार्य केंद्र या आरआईएससी माइक्रोप्रोसेसर ने इसे कभी नहीं अपनाया, हालांकि आखिरकार 20 साल बाद हम इसे एचडब्ल्यू में अच्छी तरह से लागू करने में सक्षम थे। कम से कम दुनिया अंततः इसमें बढ़ गई।)
- C89, C99, पीसीआई, यूएसबी, जावा ( अच्छा है, चाहे मानक या कल्पना, वे लगभग सभी से कड़ाई से अनुपालन को प्रेरित करने में सफल रहा है, और है कि अनुपालन सफल अंतर्संचालन में हुई।)
यह दुनिया के सबसे महत्वपूर्ण डेटाबेस के लिए चयनित होने में विफल रहा । जबकि यह एक कारण से अधिक एक डाटापॉइंट है, तथ्य यह है कि Google बिगटेबल एसक्यूएल नहीं है और रिलेशनल नहीं होना एसक्यूएल के लिए एक विरोधी उपलब्धि की तरह है।

— DigitalRoss
स्रोत

0

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

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

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

— जोसेफ फेरिस
स्रोत

1

डाउनवॉटर - इस बात की व्याख्या करने के लिए कि आप जिस चीज से सहमत नहीं हैं, उसके लिए डाउन बटन पर क्लिक क्यों करें?

— जोसेफ फेरिस

0

यहाँ कई पोस्ट यह तर्क देते हैं कि SQL खराब है क्योंकि इसमें "कोड ऑप्टिमाइज़ेशन" सुविधाएँ नहीं हैं, और इसका क्रियान्वयन योजनाओं पर आपका कोई नियंत्रण नहीं है।

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

— Adriaan
स्रोत