45

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

अंतत: मुझे समझ नहीं आ रहा है कि वह क्या पाने की कोशिश कर रहा है। क्या वह कह रहा है कि SQL को No-SQL तकनीकों से प्रतिस्थापित करें? क्या वह फाइल सिस्टम में फाइलों में डेटा स्टोर कर रहा है? या वह सिर्फ लोगों को एसक्यूएल / रिलेशनल डेटाबेस का उपयोग एससीआई के हमलों के कारण रोकना चाहता है? मुझे डर है कि वह उस बिंदु को याद कर रहा है जिसे वह बनाने की कोशिश कर रहा है।

मैं यहाँ कुछ लिंक प्रदान करूँगा ताकि आप उसके दिमाग से सीधे पढ़ सकें:

पहले, वह कहता है कि SQL को सिस्टम से पूरी तरह से हटा दिया जाना चाहिए।

समाधान। एकमात्र समाधान। सिस्टम से SQL को पूरी तरह से खत्म करना है। यदि कोई SQL इंजन नहीं है, तो कोई SQLi अटैक नहीं हो सकता है।

और यद्यपि वह एसक्यूएल को एपीआई के साथ बदलने के बारे में बात करता है, मुझे नहीं लगता कि वह एसक्यूएल को एपीआई के पीछे डालने का मतलब है कि पिछले उद्धरण के कारण और लेख में वह पहले क्या कहता है।

फ्रेमवर्क मुद्दे को संभाल नहीं है ;;

साइड नोट: एसक्यूएल कहने में, मुझे पूरा यकीन है कि रॉबर्ट का अर्थ सबसे संबंधपरक डेटाबेस है। शायद सभी नहीं बल्कि सबसे ज्यादा। किसी भी स्थिति में, अधिकांश लोग SQL रास्ते का उपयोग कर रहे हैं। इसलिए...

यदि SQL का उपयोग डेटा को बनाए रखने के लिए नहीं किया जा रहा है, तो हम क्या उपयोग करने वाले हैं?

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

मुझे ", लेकिन डेटा अखंडता" समूह पर भी प्रतिक्रिया देनी होगी। कुछ और शोधों पर, रॉबर्ट कहते हैं कि हमें डीटॉमिक जैसे ट्रांजैक्शनल डेटाबेस का उपयोग करना चाहिए । तब CRUD CR (क्रिएट और रीड) में बदल जाता है और SQL लेनदेन पूरी तरह से चले जाते हैं। डेटा अखंडता निश्चित रूप से महत्वपूर्ण है।

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

— christo8989
स्रोत

5

@ christo8989 - "SQL को API से बदलने से क्या मतलब है?"। मैं उसे व्याख्या करने का मतलब है कि आपके पास अपने कोडबस पर टेक्स्ट की क्वेरी भाषा नहीं है (जो कि एक एसक्यूएल इंजन के पास जाती है)। आप इसे एक एपीआई के पीछे छिपाते हैं जो प्रश्नों का वर्णन करने के लिए केवल सुरक्षित तंत्र को उजागर करता है। API में आंतरिक कुछ को SQL इंजन पर कमांड उत्पन्न करना होता है, लेकिन यह एक छोटा सतह क्षेत्र है जिसमें आप पैरामीटर बाइंडिंग, आदि का उपयोग लागू कर सकते हैं, नियंत्रण, जो परिवर्तन करता है, आदि

— andrew

42

लेकिन, लेकिन, लेकिन ... एसक्यूएल है एक API। यह RDBMS के लिए API है। यह सिर्फ एक बहुत ही शक्तिशाली एपीआई होता है जिसका आसानी से दुरुपयोग किया जा सकता है।

— बार्ट वैन इनगेन शेनॉ

25

आपको लगता है कि एक टेक्स्ट का इंटरफेस नहीं है एक डीबी एपीआई बनाते हैं, तो अभी या बाद में कुछ गरीब प्रोग्रामर कोड लिखने होता है कि इस तरह दिखता है: eval(request.GET["table_name"] + ".get(pk=" + request.GET["pk"] + ")"))। यह एसक्यूएल नहीं है जो वास्तव में गलती पर है, लेकिन गरीब, अज्ञानी प्रोग्रामर।

— रेयान

6

@JimmyJames SQL एक भाषा है हाँ, लेकिन इसका मतलब यह नहीं है कि यह एक एपीआई नहीं है। एसक्यूएल एक भाषा है जो कुछ अंतर्निहित भंडारण तक पहुंचने के लिए एक एपीआई प्रदान करती है।

— घन

5

@nocomprende SQL को हमेशा अनुप्रयोगों के लिए उपयोग करने के लिए डिज़ाइन किया गया था। यह वास्तव में अन्यथा बेकार होता। बिंदु हमेशा अनुप्रयोगों को अजीब कस्टम प्रारूपों के साथ खिलवाड़ किए बिना डेटा को संग्रहीत करने और पुनर्प्राप्त करने का कोई तरीका देने के लिए था या यहां तक कि डेटा को कैसे संग्रहीत किया जाता है, इसके बारे में पूरी तरह से देखभाल करने के लिए।

— घन

74

बॉब मार्टिन अपनी बात को और अधिक स्पष्ट करने के लिए स्पष्ट रूप से अतिरंजना कर रहा है। लेकिन उसकी बात क्या है?

क्या वह चाहता है कि लोग एसक्यूआई के हमलों के कारण लोगों को SQL / रिलेशनल डेटाबेस का उपयोग करना बंद कर दें?

मेरी समझ में, उस ब्लॉग पोस्ट में (आपका पहला लिंक) मार्टिन लोगों को एसक्यूएल का उपयोग करने से रोकने के लिए मनाने की कोशिश करता है, लेकिन रिलेशनल डेटाबेस नहीं। ये दो अलग-अलग चीजें हैं ।

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

हालाँकि, यह शक्ति एक लागत के लिए आती है : सुरक्षित एसक्यूएल क्वेरी / कमांड लिखना असुरक्षित लोगों को लिखने की तुलना में कठिन है। एक सुरक्षित एपीआई को "डिफ़ॉल्ट रूप से" सुरक्षित क्वेरी बनाना आसान बनाना चाहिए। संभावित रूप से असुरक्षित लोगों को अधिक मानसिक या कम से कम अधिक टाइपिंग प्रयास की आवश्यकता होनी चाहिए। यही कारण है कि मार्टिन अपने वर्तमान स्वरूप में SQL के खिलाफ ranting है क्यों IMHO है।

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

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

— डॉक्टर ब्राउन
स्रोत

2

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

— वॉलफ्रैट

7

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

— घन

3

@ क्यूबिक: मार्टिन द्वारा बताई गई समस्याओं का कोई समाधान शायद एसक्यूएल की तुलना में कम शक्तिशाली या कम आसान होना चाहिए - यही उनका आशीर्वाद और उनका अभिशाप है।

— डॉक्टर ब्राउन

1

@ बरमार: एसक्यूएल उच्च-स्तर के बारे में है जैसा कि आप प्राप्त कर सकते हैं, और बॉब यह दावा कर रहे हैं कि यह असुरक्षित रूप से असुरक्षित है।

— रॉबर्ट हार्वे

3

@ christo8989: मुझे नहीं लगता कि मार्टिन ने एक बार अपने करियर में जो भी लिखा या कहा है, उसके जवाब के रूप में एक जवाब लिखने की कोशिश करने में बहुत समझदारी होगी। मेरा उत्तर आपके शीर्षक में दिए गए प्रश्न में से एक था, जिसमें अधिकतर यह बताते हुए कि आपके द्वारा दिए गए पहले लिंक में ब्लॉग पोस्ट को IMHO कैसे व्याख्या किया जाना चाहिए।

— Doc Brown

57

बॉब मार्टिन की राय बस यही है; एक आदमी की राय।

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

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

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

हम रसोई के चाकू पर प्रतिबंध नहीं लगाते क्योंकि कुछ असहाय व्यक्ति गलती से अपनी उंगलियों को काट लेते हैं।

— रॉबर्ट हार्वे
स्रोत

16

मैं मार्टिन के लेखों की व्याख्या आरडीबीएमएस छोड़ने की वकालत करने के रूप में नहीं करता, बल्कि उनके साथ बातचीत के वैकल्पिक तरीकों का उपयोग करने के लिए करता हूं, जैसे कि LINQ-to-SQL या JPA मानदंड API, सीधे हमारे कोड में SQL स्ट्रिंग्स को एन्कोडिंग या हेरफेर करने के बजाय।

— जूल्स

27

इसलिए हमें आँख बंद करके उसका कहना नहीं मानना चाहिए ... लेकिन वह क्या कह रहा है ?

— TRIG

33

एक बात मुझे यहाँ के समुदाय के बारे में नापसंद है, जैसे ही आप क्लीन कोड / अंकल बॉब -वे के बारे में कुछ करने के बारे में सवाल पूछते हैं , क्या लोग आपको यह बताने में झपट रहे हैं कि आपको कुछ अलग कैसे करना चाहिए । "वान गाग की तरह पेंट कैसे करें?" - "वैन गॉग गलत था, आपको पिकासो की तरह पेंट करना चाहिए"।

— आर। शमित्ज़

21

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

— शाफ़्ट

17

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

15

वह वास्तव में क्या कह रहा है?

क्या वह कह रहा है कि SQL को No-SQL तकनीकों से प्रतिस्थापित करें?

TL; DR: हाँ (सॉर्ट)

मूल रूप से उसी विषय पर जिस लिंक पर आप कहते हैं, उससे अधिक हाल की बातचीत में वह कहता है: "डेटाबेस एक विस्तार है। हम डेटाबेस क्यों बनाते हैं ?" ।

उनका दावा है कि डेटाबेस कताई डिस्क से डेटा एक्सेस को आसान बनाने के लिए आया था, लेकिन भविष्य में "[...] नई तकनीक के लिए धन्यवाद नहीं होगा" और वह जिसे "लगातार रैम" कहते हैं और यह आसान हो जाएगा डेटा प्रोग्रामर का उपयोग करके डेटा स्टोर करें, जैसे हैशटैब या पेड़।

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

अगर मैं ओरेकल था, तो मुझे बहुत डर लगेगा क्योंकि मेरे अस्तित्व का कारण मेरे नीचे से वाष्पीकरण हो रहा है। [...] डेटाबेस के मौजूद होने का कारण गायब हो रहा है।

संभवतः कुछ रिलेशनल टेबल होंगे जो जीवित रहेंगे, लेकिन अब कुछ स्वस्थ प्रतिस्पर्धा है ।

तो नहीं, उसके लिए यह एसक्यूएल इंजेक्शन के बारे में ही नहीं है, हालांकि वह इस बात को स्वीकार करता है कि एसक्यूएल स्वाभाविक रूप से इस संबंध में दोषपूर्ण है ।

लेखक का ध्यान दें:

इस पोस्ट में बयान केवल इस विषय पर रॉबर्ट सी। मार्टिन के दृष्टिकोण को समझने के लिए उद्धरण हैं और लेखक की राय का प्रतिनिधित्व नहीं करते हैं। अधिक भिन्न दृष्टिकोण के लिए, रॉबर्ट हार्वे का उत्तर देखें ।

— सोरेन डी। Ptøus
स्रोत

2

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

— घन

7

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

— आमोन

3

@amon हाँ, रॉबर्ट हार्वे सही और अधिक भिन्न दृष्टिकोण पेश कर रहा है। लेकिन जब से ओपी ने विशेष रूप से रॉबर्ट सी। मार्टिन से यह कहने की कोशिश की कि मैं उनकी "नई" बात का हिस्सा हूं।

— सोरेन डी। Pt Febus

3

@amon - ऊपर डॉक्टर ब्राउन के जवाब का पहला वाक्य देखें। मार्टिन अक्सर ऐसे बयान देते हैं जो इसे प्राप्त करने के लिए अपनी बात के बड़े पैमाने पर अतिशयोक्ति हैं। उसका मतलब यह नहीं है कि सभी डेटाबेस ऑपरेशन को मेमोरी स्टोर से बदल दिया जा सकता है, किसी से भी अधिक इसका मतलब है कि आपके आवेदन का एक घटक है जो किसी न किसी रूप में एसक्यूएल को छूता है एक भारी-भरकम सुरक्षा जोखिम है जिससे इसे सभी में बचना चाहिए मामलों, अभी तक अपने शब्दों के चेहरे पर वह यह कहते हुए व्याख्या की जा सकती है। लेकिन वह जो वास्तव में करने की कोशिश कर रहा है वह सबको रोक देता है और सोचता है: क्या SQL / RDBMS मेरे आवेदन के लिए सही है?

— जूल्स

12

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

— अमोन

11

SQL एक डिटेल है। एक विस्तार का ज्ञान नहीं फैलाना चाहिए।

जैसे-जैसे SQL का उपयोग आपके कोड में अधिक से अधिक स्थानों पर होता है, आपका कोड अधिक से अधिक इस पर निर्भर होता जाता है।

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

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

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

अपनी स्वतंत्रता का एहसास किए बिना बलिदान करना आसान है। एसक्यूएल एक विकल्प एक दिया नहीं है। यदि आप एसक्यूएल का उपयोग करने का निर्णय लेते हैं तो इसे एक ही स्थान पर बनाएं। इसे इस तरह से बनाएं कि यह अनमैंड हो सके।

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

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

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

— candied_orange
स्रोत

1

गोश, आइंस्टीन, बिल्कुल।

1

आह, आइंस्टीन बॉब को नहीं जानता था। या कि बॉब भगवान थे। हालाँकि ऐसा लगता है कि यह एक मज़ेदार स्टैंडअप बिट का निर्माण करता है।

— candied_orange

9

@nocomprende आप प्रेरक पोस्टरों के एक स्थिर आहार पर रह रहे हैं?

— candied_orange 14

2

लेकिन बॉब है भगवान। कुछ के लिए कम से कम।

— पीटर मोर्टेंसन

3

मैं यह मानने से इनकार करता हूं कि ईश्वर सार्वजनिक बोलने में अच्छा है।

— candied_orange

5

आपके पहले उद्धरण से उद्धरण है (जोर मेरा),

समाधान। एकमात्र समाधान। करने के लिए है सिस्टम से एसक्यूएल को समाप्त पूरी तरह से। यदि कोई SQL इंजन नहीं है, तो कोई SQLi अटैक नहीं हो सकता है।

क्या बदलेगी SQL? बेशक एक एपीआई! और एक एपीआई नहीं जो एक पाठ्य भाषा का उपयोग करता है। इसके बजाय, एक एपीआई जो डेटा संरचनाओं के एक उपयुक्त सेट का उपयोग करता है और आवश्यक डेटा तक पहुंचने के लिए फ़ंक्शन कॉल करता है।

रेंट एप्लिकेशन प्रोग्रामर को एसक्यूएल का उपयोग करने देने के खिलाफ है।

सुझाया गया फिक्स उन्हें इसके बजाय एक एपीआई का उपयोग करने देना है: जो SQL नहीं है और इंजेक्शन की अनुमति नहीं देता है।

IMO, ऐसे API के उदाहरण शामिल हो सकते हैं:

http://bobby-tables.com/csharp सुझाव देता है कि C # प्रोग्रामर ADO.NET API का उपयोग कर सकते हैं।

यही कारण है कि एक आदर्श उदाहरण नहीं है क्योंकि ADO.NET एक विस्तृत या गहरी (यानी शक्तिशाली या सामान्य प्रयोजन) एपीआई, जो है भी इनपुट कच्चे (या कच्चे-ish) एसक्यूएल करने के लिए अपने उपयोगकर्ताओं को अनुमति देता है।
कुछ SQL डेवलपर्स या डेटाबेस प्रशासक सुझाव देते हैं कि एक डेटाबेस को इस तरह कॉन्फ़िगर किया जाना चाहिए कि यह केवल (सीमित संख्या में विशेषज्ञ लिखित) संग्रहीत प्रक्रियाओं के माध्यम से पहुंच की अनुमति देता है , और उस एप्लिकेशन डेवलपर्स को अपनी खुद की (खतरनाक) SQL क्वेरी लिखने की अनुमति नहीं दी जानी चाहिए
"सिस्टम से SQL को खत्म करने" का एक अन्य तरीका डेटाबेस (जो SQL को उजागर करता है) को किसी अन्य सिस्टम पर, REST API या समान के माध्यम से एक्सेस करना है।

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

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

आम तौर पर मुझे लगता है कि इसका मतलब है कि एप्लिकेशन-विशिष्ट DAL ("डेटा एक्सेस लेयर" या "डेटाबेस एब्स्ट्रक्शन लेयर")। एक डीएएल आवेदन को यह बताता है कि डेटा कैसे और कहां संग्रहीत किया जाता है और / या लाया गया है। SQL डेटाबेस का उपयोग करके DAL लागू हो सकता है या नहीं भी हो सकता है।

— ChrisW
स्रोत

मैंने एक ऐसे उत्पाद पर काम किया, जो ठीक 30 साल पहले किया था। और, अंतर्निहित डेटाबेस ने SQL (अभी तक) का समर्थन नहीं किया। और, एक डेटाबेस में संबंधित तालिकाओं का सेट संग्रहीत किया गया था (इसके लिए प्रतीक्षा करें ...)। जो आदमी उस के साथ आया था वह वास्तव में स्मार्ट था। हालांकि अब एक प्रोग्रामर नहीं है।

मुझे यह उत्तर पसंद है लेकिन मुझे लगता है कि वह यह नहीं कह रहे होंगे। उन्होंने यह भी कहा, "फ्रेमवर्क मुद्दे को संभाल नहीं है ..."। आपके उत्तर से, ऐसा लगता है कि आप Linq-to-Sql का उपयोग करके कह रहे हैं कि यह ठीक है लेकिन क्या इस मुद्दे को संभालने वाला ढांचा नहीं है?

— क्रिश्चियन।

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

— क्रिस डब्ल्यूडब्ल्यू

1

@ christo8989 augustl.com/blog/2016/… पता चलता है कि डेटामिक एक (संभवतः-एसक्यूएल) डेटाबेस के चारों ओर एक और आवरण / परत है - "डेटामिक सीधे फाइल सिस्टम में नहीं लिखता है। इसके बजाय, आप एक संख्या का उपयोग कर सकते हैं। डेटाबेस के लिए अलग बैकेंड के रूप में विभिन्न डेटाबेस: कोई SQL JDBC डेटाबेस, आदि। "

— क्रिस डब्ल्यूडब्ल्यू

यह ध्यान दिया जाना चाहिए कि ADO.NET में SQL इंजेक्शन से बचने के लिए समाधान यह सब जटिल नहीं है - SQL में प्लेसहोल्डर का उपयोग करें, कमांड में पैरामीटर का उपयोग करें, और कहा मापदंडों के मूल्य को सेट करें।

— ज़ेव स्पिट्ज

3

हर कोई सुरक्षा के दृष्टिकोण से या SQL लेंस के साथ इस प्रश्न का उत्तर देता प्रतीत होता है।

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

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

— कीनन
स्रोत

डेटा के बहु-उपयोगकर्ता समवर्ती पढ़ने / लिखने के बारे में वह क्या सोच सकता है?

— क्रिस डब्ल्यूडब्ल्यू

1

@ क्रिस मुझे नहीं लगता कि यह कार्यान्वयन का एक मुद्दा है, बल्कि निरंतर डेटा संग्रहण को बेहतर तरीके से करने का एक उच्च-स्तरीय विचार है।

— कीनन

@ क्रिस वो लेन-देन डेटाबेस के बारे में भी बात करता है। अपने हठ उपकरण के रूप में स्रोत नियंत्रण प्रौद्योगिकी लाना। उस में, आप केवल बनाते हैं और पढ़ते हैं जो लेनदेन और अपडेट की तुलना में अधिक समवर्ती अनुकूल है।

— क्रिस्चो8989

@ कीनन तो वह वास्तव में कार्यान्वयन के माध्यम से समाधान की पेशकश नहीं कर रहा है। वह सिर्फ कह रहा है, सोचें कि क्या हो सकता है?

— क्रिश्चियनो।

1

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

— कीनन

2

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

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

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

विरोध के रूप में

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

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

पहले संदर्भ की मेरी व्याख्या यह है कि वह सुझाव दे रहा है कि हमें एक ऐसे ज्ञात मुद्दे की जगह लेनी चाहिए जिसका एक जाना-पहचाना हल है।

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

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

हाँ कताई डिस्क अतीत की बात है, और हम अब SSDs का उपयोग करते हैं। डिस्क डेटा ट्रांसफर के प्रति ~ 10 मिलीसेकंड के साथ काम करते हैं, SSD ~ 0.5 मिलीसेकंड (500 माइक्रोसेक) डेटा एक्सेस समय के साथ काम करते हैं। रैम 100 नैनो सेकंड के क्रम पर है, प्रोसेसर 100 सेकंड के पिको सेकंड में संचालित होते हैं। यह हम क्यों डेटाबेस की जरूरत का दिल है। डेटाबेस मुख्य मेमोरी के साथ या तो कताई डिस्क या एसएसडी के बीच डेटा ट्रांसफर का प्रबंधन करते हैं। SSDs के आगमन ने डेटाबेस की आवश्यकता को समाप्त नहीं किया है।

— रॉबर्ट बैरन
स्रोत

4

"STOP USING SQL" (पहले लिंक से उद्धृत) बहुत अच्छा लगता है जैसे वह कह रहा है कि मेरी समझ में SQL का उपयोग न करें।

— डॉक्टर ब्राउन

6

यह एक शब्द आदेश मुद्दा है। वास्तव में यह मूल रूप से एक टेलीग्राम था: SQL STOP का उपयोग

6

@nocomprende तो आप कह रहे हैं कि वह एक दौड़ की स्थिति का शिकार है? खैर, उफ़। वह एसक्यूएल लेनदेन का उपयोग करके इससे बचा जा सकता था।

— कोनराड रुडोल्फ

शायद यह विजुअल बेसिक और फोरट्रान का एक बहुत छोटा मिश्रण है। इस सबका अंत क्या होगा?

1

@KonradRudolph: ठीक है, मुझे लगता है कि हम इस बात से सहमत होंगे कि वस्तुतः कोई भी असेंबली से सीधे TSX का उपयोग करने वाला नहीं है। उच्च-स्तरीय अमूर्तताएँ होंगी। क्या वे अमूर्त लेनदेन एसक्यूएल लेनदेन होंगे? मुझे नहीं लगता। एक व्याख्या की गई भाषा के रूप में, SQL एक प्रदर्शन उपरि करता है। जब आप हार्डडिस्क को घुमाने पर डेटा एक्सेस करते हैं तो वास्तव में इससे कोई फर्क नहीं पड़ता था। रैम में डेटा एक्सेस करते समय यह अप्रभावी होता है।

— 15

2

उत्तर

क्या वह सिर्फ लोगों को एसक्यूएल / रिलेशनल डेटाबेस का उपयोग करने से रोकना चाहता है क्योंकि एसक्यूआई हमलों के कारण?

'बॉबी टेबल्स' लेख से लगता है कि यह, यह और यह एसक्यूएल का उपयोग न करने का एक कारण है:

समाधान। एकमात्र समाधान। सिस्टम से SQL को पूरी तरह से खत्म करना है। यदि कोई SQL इंजन नहीं है, तो कोई SQLi अटैक नहीं हो सकता है।

उसके अन्य कारण भी हो सकते हैं कि वह अन्यत्र चर्चा करता है। मुझे नहीं पता होगा क्योंकि मैं वास्तव में उसके सामान को ज्यादा नहीं पढ़ता हूं।

विषयांतर

यह हिस्सा वास्तव में एक जवाब नहीं है, लेकिन मुझे लगता है कि एसक्यूएल के मूल्य का सवाल कहीं अधिक दिलचस्प है (जैसा कि अन्य, जाहिरा तौर पर करते हैं)।

मुझे एसक्यूएल का उपयोग करने का बहुत अनुभव है और मुझे लगता है कि मुझे इसकी ताकत और कमजोरियों के बारे में उचित समझ है। मेरी व्यक्तिगत भावना यह है कि इसका अत्यधिक उपयोग और दुरुपयोग किया गया है, लेकिन यह विचार कि हमें इसका उपयोग कभी नहीं करना चाहिए, यह मूर्खतापूर्ण है। यह विचार कि हमें 'एसक्यूएल ऑलवेज' या 'एसक्यूएल नेवर' का चयन करना चाहिए, एक गलत द्विभाजन है।

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

मुझे लगता है कि हर डेवलपर को "फ्राइडे द 13 वें: अटैकिंग जोंस - अल्वारो मुनोज एंड ओलेकेंड्रर मिरोश - अप्पसुसा 2017" शीर्षक वाले इस वीडियो को देखना चाहिए।

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

— JimmyJames
स्रोत

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

— मेरिटॉन - हड़ताल पर

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

— जिमीजैम

2

मैं केवल एक छोटा वक्तव्य देना चाहता हूं:

या वह सिर्फ लोगों को एसक्यूएल / रिलेशनल डेटाबेस का उपयोग एससीआई के हमलों के कारण रोकना चाहता है?

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

— बिलाल बेगूराज
स्रोत

2

स्वचालित कारों से लगभग 98% कार दुर्घटनाओं को रोका जा सकेगा। हमें मशीन पर अधिक भरोसा करने की जरूरत है , हे हे हे।

3

"हम यह नहीं कह सकते कि हमें कारों का उपयोग करना बंद करना चाहिए [विशेष और / या सावधानीपूर्वक नियंत्रित परिस्थितियों को छोड़कर] क्योंकि वे कार दुर्घटनाओं में मरने वाले लोगों के लिए जिम्मेदार हैं।" - उह। हम बिल्कुल ऐसा कह सकते हैं। और कई वाजिब लोग करते हैं।

— कोनराड रुडोल्फ

1

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

— Billal Begueradj

2

@BillalBEGUERADJ यह कुछ हद तक गलत तुलनीयता है (क्योंकि हैकिंग से कुछ भी सुरक्षित नहीं है), लेकिन यह पूरी तरह से दूर नहीं है: ऐसी भाषाएं हैं, जो संतुलन पर, उपयोग नहीं की जानी चाहिए क्योंकि बेहतर विकल्प हैं; उदाहरण के लिए, यदि आप सिस्टम प्रोग्रामिंग के संदर्भ में C का उपयोग कर रहे हैं तो आप इसे गलत कर रहे हैं। वैसे भी, मैं अपने जवाब downvote नहीं था, लेकिन यह है गलत: क्योंकि तुम क्या दावा के विपरीत, यह है कि वास्तव में क्या बॉब मार्टिन कह रहा है (के रूप में अन्य उत्तर दिखाएं)।

— कोनराड रुडोल्फ

2

मार्टिन की समस्या उपयोगकर्ता इनपुट से सीधे गतिशील SQL बनाने वाले प्रोग्रामर के साथ प्रतीत होती है , कुछ ऐसा है (मुझे माफ कर दो, मैं मुख्य रूप से C और C ++ प्रोग्रामर हूं):

sprintf( query, "select foo from bar where %s;", user_input );

जो बिल्कुल नाराज़गी के लिए एक नुस्खा है (इसलिए बॉबी टेबल्स स्ट्रिप)। कोई भी प्रोग्रामर जो कोड को प्रोडक्शन सिस्टम में रखता है वह पैडलीन का हकदार है। '

आप तैयार किए गए कथनों का उपयोग करके और अपने आदानों को ठीक से साफ करके समस्या को कम कर सकते हैं (यदि पूरी तरह से समाप्त नहीं करते हैं)। यदि आप SQL को API के पीछे छिपा सकते हैं जैसे प्रोग्रामर सीधे क्वेरी स्ट्रिंग्स का निर्माण नहीं कर रहे हैं, तो बहुत बेहतर (जो कि मार्टिन अधिवक्ताओं का हिस्सा है)।

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

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

— जॉन बोडे
स्रोत

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

— रॉबर्ट हार्वे

@ रोबर्टहवे: मैं यह मानूंगा कि यह मामला है। अपने हिस्से के लिए, मैं ज्यादातर C- और C ++ में सर्वर-साइड काम करता हूं, इसलिए मैं अभी भी कभी-कभी sprintfगतिशील SQL के लोगों के उदाहरणों (धन्यवाद दुर्लभ) को देखता हूं , जो कि नॉट हाउ यू डू इट।

— जॉन बोडे

1

आपके द्वारा लिंक किए गए दो स्रोत विभिन्न संदेश देते हैं:

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

व्याख्यान अलग है। पहला अंतर टोन में है: व्याख्यान सट्टा और प्रश्न में कॉल करता है, लेकिन निंदा नहीं करता है। वह यह नहीं कहता है कि डेटाबेस बुराई हैं, लेकिन डेटाबेस के बिना दृढ़ता की कल्पना करने के लिए हमें चुनौती देता है। उनका तर्क है कि 30 साल के बाद से रिलेशनल डेटाबेस व्यापक रूप से बदल गए हैं, कई चीजें बदल गई हैं, और दो पर प्रकाश डाला गया है जो दृढ़ता से हमारी दृढ़ता प्रौद्योगिकी को प्रभावित कर सकता है:

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

क्या इन बदली परिस्थितियों से इष्टतम दृढ़ता प्रौद्योगिकी बदल जाती है? दिलचस्प बात यह है कि अंकल बॉब ऐसा नहीं कहते हैं - शायद इसलिए क्योंकि उन्हें लगता है कि कोई भी जवाब सभी कार्यक्रमों के लिए सही नहीं होगा। इसलिए वह हमें दृढ़ता तकनीक के बारे में हमारी पसंद का इलाज करने के लिए सावधान करता है, बजाय इसके कि पत्थर की गोलियों में इसे निहित किया जाए और इसे अपने साथियों को ज्ञान दिया जाए।

क्या विकल्प मौजूद हैं?

स्ट्रिंग्स के बिना डेटा एक्सेस लॉजिक लिखना पूरी तरह से संभव है। जावा भूमि में, आप QueryDSL का उपयोग कर सकते हैं , जहां आपके डेटाबेस स्कीमा से उत्पन्न एक प्रकार-सुरक्षित धाराप्रवाह एपीआई का उपयोग करके प्रश्नों का वर्णन किया जाता है। ऐसी क्वेरी निम्नानुसार लग सकती है:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

जैसा कि आप देख सकते हैं, क्वेरी तर्क को स्ट्रिंग के रूप में व्यक्त नहीं किया गया है, क्वेरी के विश्वसनीय ढांचे को स्पष्ट रूप से अविश्वासित मापदंडों से अलग करना (और निश्चित रूप से, क्वेरीरीएलएल ने क्वेरी पाठ में पैरामीटर शामिल नहीं किया है, लेकिन क्वेरी को अलग करने के लिए तैयार किए गए बयानों का उपयोग करता है। JDBC स्तर पर इसके मापदंडों के लिए)। QueryDSL के साथ SQL इंजेक्शन को प्राप्त करने के लिए, आपको एक स्ट्रिंग पार्स करने के लिए अपने खुद के पार्सर को लिखना होगा और इसे एक वाक्यविन्यास ट्री में अनुवाद करना होगा, और यदि आपने ऐसा किया भी है, तो आप शायद इस तरह की चीजों का समर्थन नहीं करेंगे select ... into file। संक्षेप में, QueryDSL SQL इंजेक्शन नायकों को असंभव बनाता है, और प्रोग्रामर उत्पादकता में सुधार भी करता है और सुरक्षा को फिर से सक्रिय करता है। वेब अनुप्रयोग सुरक्षा के लिए सबसे बड़ा जोखिम रोक दिया, जो कि लंबे समय से गैगिंग स्पैंग चलाने के लिए मौजूद है, और डेवलपर उत्पादकता को बढ़ाया? मेरा कहना है कि यदि आप अभी भी प्रश्नों को तार के रूप में लिखते हैं, तो आप इसे गलत कर रहे हैं।

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

— मेरिटॉन - हड़ताल पर
स्रोत

रॉबर्ट सी। मार्टिन का SQL के अनावश्यक होने का क्या मतलब है? [बन्द है]

वह वास्तव में क्या कह रहा है?

TL; DR: हाँ (सॉर्ट)

लेखक का ध्यान दें:

उत्तर

विषयांतर