डेटाबेस फीचर्स को नजरअंदाज क्यों किया जा रहा है, और इसके बजाय मध्य स्तरीय में पुनर्निवेश किया गया है?

Question

शीर्ष कारण ( "डेटाबेस स्वतंत्रता" के अलावा ) कि अधिकांश आईटी परियोजनाएं आज Oracle 11g और SQL Server 2008 जैसे आधुनिक डेटाबेस इंजन में मौजूद सुविधाओं के धन की अनदेखी करती हैं?

या, हेलसिंकी घोषणा ब्लॉग से उधार लेने के लिए जो इसे इस तरह डालता है:

पिछले बीस वर्षों में हम देखते हैं कि कार्यक्षमता (सुविधाएँ) जो DBMS के अंदर हमारे लिए उपलब्ध है, तेजी से बढ़ी है। इन विशेषताओं ने हमें डेटाबेस एप्लिकेशन बनाने में सक्षम किया। यही वह है जो हम सभी ने नब्बे के दशक की शुरुआत में किया था।

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

हम जैसे सामान के बारे में बात कर रहे हैं

• डेटा APIs (सुरक्षा के लिए और अत्यधिक नेटवर्क ट्रैफ़िक से बचने के लिए) के रूप में उपयोग की जाने वाली संग्रहीत प्रक्रियाएँ
• भौतिकवादी विचार
• इसके बजाय ट्रिगर्स की
• पदानुक्रमित प्रश्न (द्वारा कनेक्ट करें)
• भूगोल (स्थानिक डेटा प्रकार)
• Analytics (लीड, लैग, रोलअप, क्यूब, आदि)
• वर्चुअल प्राइवेट डेटाबेस (VPD)
• डेटाबेस-स्तरीय ऑडिटिंग
• फ्लैशबैक प्रश्न
• XML पीढ़ी और XSL डेटाबेस में परिवर्तन
• डेटाबेस से HTTP कॉलआउट
• पृष्ठभूमि नौकरी अनुसूचक

इन सुविधाओं का उपयोग क्यों नहीं किया जा रहा है? अधिकांश जावा, .NET और PHP डेवलपर्स "सेलेक्ट * FROM mytable" दृष्टिकोण के साथ क्यों चिपके हुए हैं?

Comments

+1 अच्छी बातचीत- framer।

— डेन रोसेन्स्टार्क

क्या आप इसे आउटर जॉइन प्रस्ताव के लिए एक नमूना प्रश्न के रूप में पोस्ट कर सकते हैं: area51.stackexchange.com/proposals/4260/outer-join (मैं इसे करूंगा और अटेंशन प्रदान करूंगा, लेकिन मैं पहले से ही अपनी 5 प्रश्न सीमा पर हूं)

— जो

Answer 1

क्योंकि संग्रहीत कार्यविधियाँ:

• एक और विकास भाषा, बढ़ती जटिलता और संभावित अनावश्यक कोड जोड़ें (दोनों भाषाओं में लिखित तर्क);
• आमतौर पर PHP, C #, जावा, पायथन, आदि की तुलना में बदतर टूलींग, निगरानी और डिबगिंग क्षमताएं हैं;
• अधिकांश मध्यम स्तरीय भाषाओं की तुलना में आम तौर पर कम सक्षम होते हैं;
• केवल उच्च मात्रा डेटा परिवर्तन (जहां आप सर्वर राउंडट्रिप से बचते हैं) के साथ एक फायदा है, जो केवल वास्तविक उपयोग का एक न्यूनतम हो जाता है।

यह कहा जा रहा है, यह C # ASP.NET अनुप्रयोगों पर एक सामान्य पद्धति है।

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

मैंने अक्सर भौतिक विचारों का उपयोग किया है और कभी-कभी Oracle में CONNECT BY का उपयोग किया है, जिनमें से न तो मेरा मानना ​​है कि MySQL में मौजूद है।

मैं डेटाबेस में XML / XSLT का उपयोग नहीं करता हूं, क्योंकि, इसका मतलब है कि मैं XML और XSLT का उपयोग कर रहा हूं।

भौगोलिक या स्थानिक डेटा संरचनाओं के लिए, कारण यह है कि संभवतः वे "पिक अप" के लिए कठिन हैं। यह काफी विशेषज्ञ क्षेत्र है। मैंने स्थानिक डेटा संरचनाओं पर MySQL मैनुअल पढ़ा है और मुझे यकीन है कि यह व्यापक जीआईएस अनुभव वाले किसी व्यक्ति के लिए समझ में आता है, लेकिन मुझे और मेरी सीमित जरूरतों के लिए (जो एक बिंदु के अक्षांश / देशांतर को चिह्नित करने के लिए होता है) यह सिर्फ doesn यह पता लगाने के लिए समय निवेश के लायक नहीं है।

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

Comments

मैं इस तथ्य को जोड़ूंगा कि संग्रहीत प्रक्रियाएं शायद ही कभी स्रोत नियंत्रण में रखी जाती हैं।

— मुसैनेसिस

खैर, यह सच हो सकता है लेकिन ऐसा कोई कारण नहीं है कि उन्हें स्रोत नियंत्रण में नहीं रखा जा सकता है ।

— cletus

हमारे सभी एसपीएस स्रोत नियंत्रण में हैं, यह एक बहाना नहीं है

— HLGEM

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

— डैनियल प्रीडन

मैं इस बात से सहमत हूं कि एसपी "उच्च मात्रा डेटा परिवर्तन (जहां आप सर्वर राउंडट्रिप से बचते हैं) के साथ एक फायदा है"। हालाँकि, फिर आप कहते हैं कि "केवल वास्तविक उपयोग की ओर जाता है"। मुझे लगता है कि यह बहस का चरम है: यदि आपके पास एक एप्लिकेशन है जहां उच्च मात्रा डेटा परिवर्तन का उपयोग न्यूनतम है, तो बहुत सारी डेटाबेस कार्यक्षमता जोड़ना इसके लायक नहीं है। हालांकि, यदि आपके पास एक तालिका में एक अरब से अधिक रिकॉर्ड हैं, और आपको 0.1 सेकंड में 24 8-घंटे स्लाइडिंग औसत का चयन करने की आवश्यकता है, तो डेटाबेस बहुत बेहतर समाधान होने लगता है। सही उत्तर वास्तव में आपके आवेदन पर निर्भर करता है।

— डैनियल प्रीडन

Answer 2

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

यही कारण है कि मुझे उपकरण iBATIS पसंद है । वे आपको डीबीएमएस विशिष्ट विशेषताओं सहित एसक्यूएल लिखते और समझते हैं।

Comments

इसलिए मैंने आपके लिंक को देखा। । । मैं एक ORBATIS नहीं है? सिर्फ एक आपको एक उपकरण होने के बजाय इसे आपके लिए परिभाषित करना होगा?

— andrewWinn

नहीं, iBATIS कोई ORM नहीं है, यह एक क्वेरी मैपर है। यह टेबल पर ऑब्जेक्ट्स को मैप नहीं करता है, लेकिन किसी भी भाषा संरचना, ऑब्जेक्ट या नहीं पर क्वेरी करता है।

इसलिए आप इसे बताएं कि आपके लिए यह करने के बजाय क्या वस्तुएं (क्वेरी परिणाम और क्या नहीं) हैं?

— andrewWinn

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

— डैनियल प्रीडन

@andrewWinn: संपूर्ण बिंदु यह है कि आप डेटाबेस का उपयोग CRUD फ़ंक्शन की तुलना में बहुत अधिक कर सकते हैं ।

— डैनियल प्रीडन

Answer 3

मुझे लगता है कि एक कारण वेंडर लॉकिन का डर है।

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

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

Comments

डेटाबेस से ORM के लिए अधिक वेंडर लॉकिन। विशेष रूप से वेब-आधारित अनुप्रयोगों के लिए डेटाबेस को बदलने की आवश्यकता बहुत कम है।

— HLGEM

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

— मार्को

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

— डैनियल प्रीडन

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

— मार्को

Answer 4

"डेटाबेस सुविधाओं को अनदेखा क्यों किया जा रहा है"।

क्योंकि बहुत सारे तथाकथित डेवलपर्स डेटा प्रबंधन के बारे में पूरी तरह से अनभिज्ञ हैं, और जो भी बदतर है, वे पूरी तरह से अपने अज्ञान से भी अनभिज्ञ हैं। "इसके बारे में अनजान और अनजान", जिसके लिए यह घंटी बजती है।

Comments

मैं कुछ डेवलपर्स को जानता हूं, और मैं वास्तव में सक्रिय नहीं हूं, मैं ज्यादातर स्थानिक डेटाबेस (मॉडलिंग / डीबीए) के साथ काम करता हूं, लेकिन यह इतना सच है। डेवलपर्स को यह पता नहीं लगता है कि डेटाबेस का उपयोग करने के लिए एक आसान, समझदार बनाना और मेनटेन करना एक जटिल काम है।

— जॉर्ज सिल्वा

Answer 5

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

Comments

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

— थियो लेन्डॉर्फ

Answer 6

मुझे लगता है कि एक कारण वेंडर लॉकिन का डर है। इन DBMS सुविधाओं को मानकीकृत नहीं किया जाता है - उदाहरण के लिए, संग्रहीत कार्यविधियाँ बहुत DB विशिष्ट हैं, और यदि आपने संग्रहीत प्रक्रियाओं का उपयोग करके सामान लागू किया है (इसके बजाय, मध्य स्तरीय के माध्यम से उजागर की गई वेब सेवाएँ), तो आप हमेशा DBMS के साथ पहले चुने गए हैं। , (जब तक आप DBMS को बदलना चाहते थे, तब तक इसे दूसरे DBMS में फिर से लागू करने के लिए समय / धन खर्च करने को तैयार नहीं हैं, यानी)।

Comments

मैं कभी ऐसे प्रोजेक्ट पर नहीं गया जहाँ चुने गए RDMS को बाद में बदल दिया गया।

यहां तक ​​कि एक संस्करण से दूसरे संस्करण में परिवर्तन होने के कारण ब्रेकिंग परिवर्तन हो सकते हैं।

— एंड्रयू

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

— Chii

@lutz: मैं है एक स्थिति है जहाँ हम डीबीएस बदल दिया गया। (हमने 10+ वर्ष पुराने Oracle 8 इंस्टॉल में अधिकतम तालिका आकार मारा, और DB को अपग्रेड करने के लिए कोई पैसा नहीं था, माइग्रेट करना था ... जिसका मतलब था कि सब कुछ फिर से लागू करना।) हमने शायद इससे अधिक मानव-घंटे बिताए। ओरेकल लाइसेंस के लिए लागत है, लेकिन उन के लिए बजट किया गया था।

— जो

@ लुट्ज़: आमीन। डेटाबेस ब्रांड स्विच को संभालने के लिए एक सिस्टम का निर्माण करना सड़क को "पहले से डाल सकता है" का एक क्लासिक मामला है, सिवाय इसके कि यह "डालने से पहले नहीं होगा" जैसे अधिक है।

— मुसैनेसिस

Answer 7

माई एसक्यूएल।

जब 1990 के दशक के अंत और 2000 के दशक की शुरुआत में वेब एप्लिकेशन में विस्फोट हुआ, तो MySQL 3.3 या 4.0 संस्करण में था और सरल से ऊपर कुछ भी समर्थन नहीं करता था SELECT एस के । यह, हालांकि, अधिकांश लिनक्स वितरण के साथ मुक्त, और इंस्टॉल किया गया था। नतीजतन, प्रोग्रामर की एक पीढ़ी डेटाबेस के बारे में नहीं जानती थी और यह नहीं जानती थी कि उनका उपयोग कैसे किया जाए।

अब भी जब MySQL 5.1 पर है और एक वाणिज्यिक प्रणाली की अधिकांश विशेषताओं का समर्थन करता है, तो वही पुराना ब्लॉग और लेख टेम्पलेट के रूप में उपयोग किए जाते हैं जब एक नई LAMP परियोजना को बंद कर दिया जाता है, और MySQL को MyISAM तालिकाओं और 3.3-युग की कार्यक्षमता के साथ तैनात किया जाता है। ।

Comments

+1। MySQL ने सामान्य से डेटाबेस की प्रतिष्ठा और इसका उपयोग करने वाले प्रोग्रामर्स दोनों के लिए - अच्छे से अधिक नुकसान पहुंचाया है।

— डैनियल प्राइडेन

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

— कीथ विलियम्स

Answer 8

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

मात्र नश्वर भी सबसे सरल भाषा के साथ असफल हो जाते हैं। शायद 10 में से 1 व्यक्ति के पास C # जैसी सीधी भाषा का उपयोग करने का कौशल है। लेकिन उन 10% में, सभी लोगों में से केवल 1 में 10 या 1% प्रभावी रूप से SQL या Haskell जैसी भाषाओं का उपयोग कर सकते हैं।

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

एक दूसरी समस्या यह है कि SQL प्रभावी रूप से Source Versioning के साथ बहुत संगत नहीं है। एसक्यूएल वास्तव में इस धारणा के साथ बनाया गया है कि आप इसे पहली बार सही पाते हैं। इसलिए, यह केवल डेवलपर्स के लिए बीमार-अनुकूल नहीं है, यह विकास प्रक्रिया के लिए एक खराब मैच भी है।

Comments

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

— जॉइन के

वाह, बिल्कुल गलत। SQL, C # या .Net का उपयोग करके सीखने और उपयोग करने (और अच्छी तरह से उपयोग करने) के लिए आसान परिमाण का एक क्रम है। ज्यादातर प्रोग्रामर अभी कोशिश नहीं करते हैं।

— RBarryYoung

SQL में घोषणात्मक वाक्यविन्यास है, COBOL प्रक्रियात्मक है, इसलिए आपके "तथ्य" कमजोर हैं। मैंने 30 से अधिक विभिन्न भाषाओं को सीखा है और एसक्यूएल बिना किसी प्रश्न के सबसे आसान सीखने के लिए था, उस समय इसे वापस बनाने के साथ-साथ कई अध्ययन किए गए (और सामान्य रूप से घोषित भाषाएं, अनिवार्य लोगों की तुलना में सीखना आसान है) । यही कारण है कि एक चिंता के रूप में .net ने इस तथ्य को कम नहीं किया है कि कोई भी एपीआई w 20k + प्रवेश बिंदु सीखने और प्रवीण होने में काफी समय लेता है।

— RBarryYoung

RBarry यंग, ​​मैं आपकी टिप्पणी को एक लाख बार बढ़ाऊंगा अगर मैं कर सकूं

— HLGEM

लकीलिंडी - यह मुख्य रूप से है क्योंकि नए प्रोग्रामर को SQL की तुलना में C # में अधिक अनुभव है। एसक्यूएल अक्सर एक सीधे-से-और-बिंदु घोषणात्मक भाषा है। कोड लिखने और समझने के लिए इसके स्पष्ट लाभ हैं। डेवलपर्स तकनीकी OOP और डिजाइन पैटर्न मामलों के बजाय व्यावसायिक समस्या पर ध्यान केंद्रित कर सकते हैं। यह एक मुख्य कारण है जो हम LINQ जैसी सुविधाओं को देख रहे हैं जो इन लाभों को अनिवार्य भाषाओं में लाते हैं।

— जेसन क्रसोवेती

Answer 9

DBMS की तुलना में मध्य स्तरीय को ठीक करना / फिर से तैयार करना आसान है।

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

Answer 10

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

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

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

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

... मैं इस सवाल को 'जैसे कि अधिक लोग भाषा में सुविधा x का उपयोग क्यों नहीं करते हैं' के रूप में देखते हैं - यदि वे भाषा में विशेषज्ञ नहीं हैं तो उन्हें पता नहीं होगा कि x मौजूद नहीं है।

(और इसे डीबीए प्रमाणीकरण प्राप्त करने के लिए समर्थन के रूप में नहीं लेते हैं ... मुझे कुछ ओरेकल डीबीए ज्ञात हैं जो गीले बोरे से अपना रास्ता नहीं बना सकते हैं; मैंने 8i दिनों में सभी पाठ्यक्रमों को लिया है, लेकिन परीक्षण लेने से इनकार कर दिया क्योंकि मैं उस समूह के साथ रहना नहीं चाहता था)

Comments

PostgreSQL में स्थानिक डेटा प्रकारों के लिए समर्थन है।

— जॉर्ज सिल्वा

PostGIS ( postgis.refractions.net ) पीजी का उपयोग करने के लिए एक मानक कारण है यदि आप पहले से ही नहीं हैं :)

— ग्रीग लिंड

Answer 11

मुझे लगता है कि सबसे बड़ा कारण यह है कि सभी शेष ओवरशैड हैं कि रिलेशनल डेटाबेस सिस्टम नाटकीय रूप से अधिक महत्वपूर्ण हो जाता है जब कई एप्लिकेशन एक ही डेटा साझा कर रहे हैं। कोडड के प्रसिद्ध पेपर का शीर्षक है "ए रिलेशनशिप मॉडल ऑफ डेटा फॉर लार्ज शेयर Data Banks" (जोर मेरा) है।

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

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

Comments

शायद आपको यह जानकर आश्चर्य नहीं होगा कि डीडीडी डेवलपर्स अब "एक सच्चे डेटाबेस" को एक विरोधी पैटर्न मानते हैं। नवीनतम प्रवृत्ति भ्रष्टाचार विरोधी परतों के माध्यम से समन्वयित कई डेटाबेस है।

— डैनियल ऑगर

Answer 12

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

Comments

तो ... आप "लोड-संतुलित एप्लिकेशन सर्वर के पूरे फ़ार्म" का उपयोग कर सकते हैं, लेकिन आप लोड-संतुलित डेटाबेस सर्वरों के पूरे फ़ार्म का उपयोग नहीं कर सकते ...? क्योंकि आपको अभी पता नहीं है कि कैसे? फिर आपको संभवतः डेटाबेस क्लस्टरिंग और प्रतिकृति के बारे में जानने की आवश्यकता है। क्योंकि यह निश्चित रूप से संभव है।

— डेनियल प्राइडेन

क्षमा करें, मुझे योग्य होना चाहिए कि मेरे पास केवल SQL सर्वर का अनुभव है, जो AFAIK लोड-संतुलन का समर्थन नहीं करता है, केवल विफल-ओवर।

— क्रिश्चियन हैटर

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

— डैनियल प्रीडन

@ डैनियल - लोड बैलेंसिंग एप सर्वर, लोड बैलेंसिंग डेटाबेस सर्वर की तुलना में बहुत आसान है। साथ ही, अतिरिक्त डेटाबेस सर्वर (ओ / एस और मानक मल्टी-सीपीयू सर्वर मिलता है) खरीदने के लिए आम तौर पर बहुत सस्ता होता है, अतिरिक्त डेटाबेस सर्वर (ओ / एस + एक्सपेंसिव डीबी लाइसेंस + बीफी डीबी सर्वर के साथ फास्ट ड्राइव, टन के साथ। स्मृति के आदि)

— बीप बीप

@ डैनियल प्रेडेन: आप अपने खुद के बयानबाजी के सवाल का जवाब देते हैं। "आप केवल लोड-संतुलित डेटाबेस सर्वर के पूरे फ़ार्म का उपयोग नहीं कर सकते क्योंकि ..." आपको इसके लिए नाक के माध्यम से भुगतान करने के लिए तैयार रहना होगा।

— कॉक्सी

Answer 13

मैं बहुत सी स्थितियों में रहा हूं, जहां कॉर्पोरेट राजनीति ("हमने SQL सर्वर तक पहुंच की अनुमति दी है ताकि लाखों पंक्तियों को संसाधित करने और किसी अन्य तालिका में लाखों पंक्तियों के साथ जुड़ने के लिए प्रवेश की तरह कम शक्तिशाली DBMS स्थापित कर सकें, और उस आयात को स्वचालित कर सकें" .. ") या यहां तक ​​कि तकनीकी राजनीति जो हो सकती है (" मुझे पता है कि एक्सेस डेटा की मात्रा को संभाल सकता है और भले ही यह एमडीबी को कई एमडीबी में विभाजित कर सकता है और उन्हें संदर्भ नहीं दे सकता है ..... ")

ऊ। कॉर्पोरेट राजनीति और तकनीकी राजनीति या यहां तक ​​कि अज्ञानता ने मुझे कई विशेषताओं का उपयोग करने से रोका है।

एक अन्य उदाहरण - मुझे 100% Microsoft दुकान में संग्रहीत प्रक्रियाओं का उपयोग नहीं करने का कोई कारण नहीं दिखता है जहां SQL सर्वर पसंद का DBMS है। लेकिन, क्योंकि आईटी व्यक्ति जो अंततः समाधान के लिए जा रहा था, एसपी पर "प्रकाश" था, मुझे अन्य उपायों का सहारा लेना पड़ा। मेरा मतलब है, इस बात का एक आदर्श उदाहरण है कि क्यों कुछ "फीचर" उनकी दुकान पर उनके द्वारा अनदेखा किया गया था।

मुझे पता है कि एक और दुकान जो अभी भी डॉस फॉक्सप्रो 2 का उपयोग करती है क्योंकि उनके एकमात्र आईटी व्यक्ति ने मौजूदा सिस्टम को इस तरह लिखा था और इस तरह से सभी नए सामान विकसित किए जाएंगे। क्यों? खिचड़ी भाषा हम समय के साथ चलते हैं? वहाँ पर विपणन करने वाले लोगों में से कई के पास एक ही बार में कई डॉस संकेत हैं, फॉक्सप्रो "नौकरियों" के साथ उनमें से सबसे बदसूरत रिपोर्टों का उत्पादन करने के लिए चल रहा है जो मैंने कभी देखा है। लेकिन यह काम करता है - मैं उन्हें दे दूँगा। यह काम करता है - उनकी मुख्य तालिका में 12 मिलियन पंक्तियां हैं और 50+ अन्य तालिकाएं हैं जो वे उस मुख्य तालिका के साथ 'जुड़ते हैं' (सभी 50 बार एक बार स्पष्ट रूप से नहीं) लेकिन आदमी ... इसका 1991 का अच्छा अतीत! वे उस बुलेट सूची में से एक आइटम पर भी चर्चा नहीं करना चाहते हैं जिसे आपने अपने प्रश्न में प्रदान किया है।

इस तरह से मैं क्यों अनुमान लगाता हूं।

Answer 14

मैं कहूंगा कि सबसे बड़ा कारण यह है कि ज्यादातर लोग उनके बारे में नहीं जानते हैं। एक बार किसी ने किसी समस्या का हल खोज लिया, जो कि समान लोगों के लिए डिफ़ॉल्ट समाधान बन जाता है। सेलेक्ट * FROM टेबल ने बहुत से लोगों के लिए लंबे समय तक काम किया है, इसलिए वे पुरानी समस्याओं के नए दृष्टिकोण को देखकर परेशान नहीं होते हैं।

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

Answer 15

अच्छा सवाल, और अच्छी चर्चा।

इसे लगाने का दूसरा तरीका यह है कि "डीबी को क्यों नहीं पकड़ा गया?" जो सिक्के का दूसरा पहलू है। DBs एक कष्टप्रद अमूर्तता है जो अभी भी हर ऐप में अपना रास्ता लीक करता है, लेकिन वे आधुनिक अनुप्रयोगों के OO तर्क से असंगत हैं।

यह वास्तव में मामलों की एक विचित्र स्थिति है जिसे हम ActiveRecord, Hibernate, और अन्य बिचौलियों में DB की कार्यक्षमता को छिपाते हैं और उसकी नकल करते हैं। लेकिन यह टूटने के बिंदु पर प्रतिमानों के लिए होता है ("ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल")। क्या हम कभी डेटाबेस प्रौद्योगिकियों के लिए संक्रमण करेंगे जो हमारे ओओ ऐप (जैसे, ऑब्जेक्ट डीबी) के समान हैं?

जवाब "लंबे समय तक नहीं है" और इस बीच, उम्मीद करें कि डीबी को नजरअंदाज कर दिया जाए और कई मामलों में सिर्फ पंक्ति भंडारण के लिए इस्तेमाल किया जाए, क्योंकि अंतर को पाटने के लिए मध्य स्तरीय कार्यक्षमता में वृद्धि होती है।

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

Answer 16

क्या ईसाई पर अग्रिम करने के लिएस्केलेबिलिटी के बारे में ने कहा, ।

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

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

आजकल, अन्य एप्लिकेशन प्रोटोकॉल अधिक आम हैं (CORBA, DCOM, रिमोट EJB, और अधिक से अधिक सामान्य आज XML / JSON / HTTP-RPC स्टाइल प्रोटोकॉल HTTP पर)। अधिकांश डेटाबेस सीधे उन प्रोटोकॉल का जवाब नहीं देते हैं, इसलिए उन कॉल को इंटरसेप्ट करने के लिए एक एप्लीकेशन लेयर को इंटरसेप्ट किया जाता है, और वह लेयर डेटाबेस को कॉल करता है।

लेकिन जैसा कि हमने सीखा है कि अब हमें इस परत में तर्क देने के लिए एक और अधिक लचीलापन मिलता है। उपकरणों की व्यापक पसंद, कैशिंग या फ़ेलओवर पर अधिक लचीलापन, या, यहां तक ​​कि डेटाबेस तकनीक (RDMBS, OODBMS, CouchDB जैसे दस्तावेज़ स्टोर)। यह "नया", 3 टीयर, जोड़ा जटिलता के बावजूद, यह पेश की गई जटिलता की तुलना में अधिक लचीलापन और शक्ति जोड़ता है।

जब आपका ऐप टीयर, स्टोर्ड प्रोसीजर के शीर्ष पर बहुत पतला लिबास होता है, तो यह सवाल करने के लिए वैध है कि यह बिल्कुल भी क्यों है।

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

फिर भी, हालांकि, तीसरा स्तर एक आधुनिक प्रणाली में लचीलापन जोड़ने में काफी मददगार है।

Answer 17

मेरे लिए, इसका कारण न केवल मेरे अनुप्रयोग डेटाबेस अज्ञेयवादी हैं, बल्कि एक डेटाबेस बुनियादी सीआरयूडी कार्यों को सबसे बेहतर बनाता है। हाँ, डेटाबेस अत्यधिक अनुकूलित हैं, और HTTP कॉलआउट करने में सक्षम हो सकते हैं, लेकिन आप ऐसा क्यों करेंगे? एक वेबबेस सेवा / वेब एप्लिकेशन HTTP कॉल के लिए अनुकूलित है, डेटाबेस के लिए नहीं। जैसे किसी एप्लिकेशन को डेटाफ़ाइल से सीधे कनेक्ट करने और डेटा को पुनः प्राप्त करने के लिए डिज़ाइन नहीं किया गया है। क्या यह किया जा सकता है? हां लेकिन क्यों? वह यह नहीं कि आपका आवेदन किस पर लागू होता है।

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

Comments

मुद्दा यह है कि आप डेटाबेस का उपयोग सीआरयूडी कार्यों की तुलना में बहुत अधिक कर सकते हैं। यदि आप सभी की जरूरत है CRUD, तो sqlite का उपयोग करें। मुद्दा यह है कि यदि आप बड़े डेटासेट (कम से कम दस लाख से अधिक पंक्तियों) पर डेटा प्रोसेसिंग, विशेष रूप से आंकड़े, औसत, या प्रक्षेप, कर रहे हैं, तो डेटाबेस में एसक्यूएल में व्यायाम करने के लिए आसान अन्य सुविधाओं की एक पूरी श्रृंखला है सी#। दिलचस्प बात यह है कि LINQ, समान कार्यक्षमता का एक बहुत कुछ जोड़ रहा है, अनिवार्य रूप से डेटाबेस कार्यक्षमता और SQL- जैसा घोषित सिंटैक्स C # में बनाता है। पूरे मुद्दा यह है कि डाटा प्रोसेसिंग है है क्या डेटाबेस उत्कृष्टता पर!

— डैनियल प्रीडन

मैं आपकी बात देखता हूं, और मेरे लिए, आंकड़े और क्या नहीं एक पढ़ने के कार्य का हिस्सा हैं। मुझे डीबी का फायदा http कॉल करने या एक्सएमएल दस्तावेज जेनरेट करने में नहीं दिखता। यह स्पष्ट रूप से एक डेटाबेस की विशिष्ट विशेषताओं के लिए आपके आवेदन को जोड़ता है, और एक प्रमुख पुनर्लेखन के बिना किसी अन्य DB विक्रेता के लिए आवेदन को पोर्ट करने के किसी भी अधिभोग को कम करता है। । । क्या आप कभी MySQL से SQL सर्वर पर गए हैं? वाक्यविन्यास में पर्याप्त भिन्नताएं हैं और क्या नहीं कि एक जटिल क्वेरी जैसा दिखने वाला कुछ अधिक बार होगा, फिर से लिखना नहीं होगा। इस प्रकार नई त्रुटियों को शुरू करने की संभावना बढ़ रही है।

— andrewWinn

Answer 18

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

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

जब यह ज्यादातर सीआरयूडी को सौंपे जाने की बात आती है:

लंबे उत्तर: मुझे लगता है कि RDBMS दुनिया परिपक्वता के बढ़ते दर्द से गुजर रही है, और यह दुनिया में जगह पा रही है। सच्चाई: OOP RDBMS से पुराना है। OOP सिर्फ दर्द और बढ़ती परिपक्वता से बाहर निकल रहा है। मुझे लगता है कि भाषा के रूप में एसक्यूएल बहुत परिपक्व है, लेकिन एक आरडीबीएमएस को क्या संभालना चाहिए इसका विचार बस व्यवस्थित हो रहा है। RDBMS जावा और C # के आसपास आने तक अधिकांश वेब ऐप्स के लिए व्यावसायिक तर्क धारक था। मुझे लगता है कि हम अभी इस सुधार को महसूस करना शुरू कर रहे हैं।

कहा जा रहा है, मुझे नहीं लगता कि कोई भी ORM डिज़ाइनर आपको यह बताने जा रहा है कि RDBMS को खिलाए गए sql स्टेटमेंट की गुणवत्ता कोई मायने नहीं रखती है।

जब यह गैर-सीआरयूडी की बात आती है तो मेरे पास यहां कोई जवाब नहीं है। अभी भी मुझे पता है कि ज्यादातर दुकानें ईटीएल / आदि के लिए डीबी का उपयोग करती हैं ...

Comments

"इडियट" एक ऐसा ही सशक्त शब्द है। शायद "भोली" , "आलसी" , या "अनुभवहीन" नास्तिकता के बिना भी उतना ही सटीक होगा। मुश्किल से।

— स्टु थॉम्पसन

अच्छी बात। मैंने कुछ हद तक जवाब को ख़त्म कर दिया है। मैं भोली के साथ गया।

— डैनियल ऑगर

Answer 19

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

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

Answer 20

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

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

Answer 21

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

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

यदि प्रदर्शन समस्याएं हैं, तो मैं चाहता हूं कि वे वेब सर्वर एप्लिकेशन स्तर पर हों। कम से कम तब मेरा एक विकल्प दूसरे वेब सर्वर को जोड़ना और लोड वितरित करना है।

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

Answer 22

कुछ पोस्ट ध्यान दें कि यह db लेयर की तुलना में एप्लिकेशन लेयर पर स्केल करना सस्ता है।

एक अन्य विचार समग्र अनुप्रयोग हैं जो कई डेटा स्टोर तक पहुंचते हैं। डीबी परत में अलग-अलग प्लेटफ़ॉर्म विशिष्ट प्रश्नों की तुलना में ऐप टीयर में प्लेटफ़ॉर्म एग्नॉस्टिक क्वेरी भाषा को लिखना और बनाए रखना बहुत आसान है।

Answer 23

क्योंकि ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर लिखना, होस्ट भाषा में, मूल होस्ट-भाषा ऑब्जेक्ट्स के साथ, प्रक्रियात्मक सॉफ़्टवेयर लिखना धड़कता है।

Answer 24

मैंने हमेशा सिस्टम पर काम किया है जो कई क्लाइंट्स को बेचा जाता है और क्लाइंट के हार्डवेयर पर चलता है। इससे यह होगा:

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

तो उपरोक्त सभी को देखते हुए, एक डेटाबेस सुविधा का उपयोग करने से लाभ होना चाहिए इससे पहले कि यह दीर्घकालिक दर्द के लायक हो।