जोड़ आलसी लोगों के लिए हैं?

169

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

उसके लिए जुड़ने वाले आलसी लोगों के लिए हैं जो प्रदर्शन की परवाह नहीं करते हैं। क्या ये सच है? क्या हमें जॉइन करने से बचना चाहिए?

c# java sql join

— बास्तियन वंदामे
स्रोत

114

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

— हाफडॉन

91

प्रोग्रामिंग भाषा आलसी लोगों के लिए है; वे सीपीयू निर्देशों को हाथ से कोड करने की तुलना में कम कुशल हैं। :)

— माइकल मैकगोवन

76

डेवलपर का नाम क्या है? मैं यह सुनिश्चित करना चाहता हूं कि मैं उसे कभी नौकरी पर न रखूं।

— जो

39

@ मिचेल मेह, असली प्रोग्रामर तितलियों का इस्तेमाल करते हैं ...

— मार्क ग्रेवेल

14

अपने "यह सच है" - नहीं, यह नहीं है। डेटाबेस सेट सिद्धांत के माध्यम से काम करते हैं; मिलती सेट बहुत अच्छी तरह से और उपयोगी ढंग से काम पर ...

— मार्क Gravell

188

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

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

मेरे सिर के ऊपर से, मैं एक भी परिदृश्य की कल्पना नहीं कर सकता, जहां एक सही ढंग से इस्तेमाल की जाने वाली समतुल्य क्लाइंट-साइड ऑपरेशन की तुलना में धीमी हो।

संपादित करें: कुछ दुर्लभ मामले हैं जहां कस्टम क्लाइंट कोड चीजों को एक सीधे DB से जुड़ने की तुलना में अधिक कुशलता से कर सकता है (मेरिटॉन द्वारा टिप्पणी देखें)। लेकिन यह बहुत अपवाद है।

— माइकल बोर्गवर्ड
स्रोत

1

3-रास्ता जुड़ने के बारे में क्या? क्या ऐसे मामले नहीं हैं जहाँ आप उन्हें "कोड में" करना बेहतर समझेंगे?

— 13

56

यदि नेटवर्क पर भेजे गए परिणाम में डेटाबेस पर गंभीर अतिरेक का कारण बनता है, तो ऐप सर्वर में शामिल होना अधिक कुशल हो सकता है। तालिकाओं ए और बी पर विचार करें, जहां ए में प्रत्येक पंक्ति बी में 20 पंक्तियों से जुड़ी है, बी में केवल 100 पंक्तियां हैं, और हम बी से संबद्ध पंक्तियों के साथ ए से पहली 1000 पंक्तियों को प्राप्त करना चाहते हैं, डेटाबेस में शामिल होने के परिणामस्वरूप 20 हो जाएंगे। * पूरे नेटवर्क में 1000 ट्यूपल भेजे गए। यदि ऐप सर्वर में शामिल हो जाता है (पहले बी तालिका को मेमोरी में लाना), तो पूरे नेटवर्क में 100 + 1000 पंक्तियाँ भेजी जाती हैं।

— मेरिटॉन

7

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

— मेरिटॉन

13

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

— rivalk

2

@meriton मैं थोड़ा हैरान हूँ; मैं ग्राहक लाइब्रेरी से क्रॉस जॉइन्ट करने की उम्मीद करूँगा।

— फिल लेलो

83

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

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

संक्षेप में: मैं असहमत हूं। RDBMS में, जोड़ मौलिक होते हैं । यदि आप उनका उपयोग नहीं कर रहे हैं, तो आप इसे RDBMS के रूप में उपयोग नहीं कर रहे हैं।

— मार्क ग्रेवल
स्रोत

46

खैर, वह सामान्य मामले में गलत है।

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

— sehe
स्रोत

1

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

— लेजेंडल्रिक्स

1

@LegendLength मैं कहूंगा कि अगर वे इतने स्मार्ट नहीं हैं तो यह सच भी है। स्मार्टनेस मानने की ज़रूरत नहीं है क्योंकि वे वही गलतियाँ करते हैं जो हम याद करते हैं (वास्तव में, मेरे लिए इसका मतलब यह हो सकता है कि वे इतने स्मार्ट नहीं हैं ...) यह सरल है: यह शायद ही कभी खारिज करने में मदद करता है। एक बार थोड़ी देर में, गलत होना ठीक है!

— सेह

24

नहीं, आपको नहीं करना चाहिए।

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

एक तरफ के रूप में, बिना जोड़ के, एक डेटाबेस का उपयोग करने में क्या बिंदु है? वह केवल पाठ फ़ाइलों का उपयोग कर सकता है।

— richzilla
स्रोत

2

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

— पिस्कोर ने

19

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

— MJB
स्रोत

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

— बस्तियन वंदाममे

3

@ ड्रेन डेन: जॉन्स आलसी लोगों के लिए हैं, हां। तथ्य यह है कि वे संभवतः अच्छा प्रदर्शन करेंगे ऑर्थोगोनल है।

— पिस्कोर ने

16

उम्म, जुड़ता है कि कैसे संबंधपरक डेटाबेस एक दूसरे से तालिकाओं से संबंधित हैं। मुझे यकीन नहीं है कि वह क्या कर रहा है।

एक कॉल से डेटाबेस के लिए कई कॉल करना अधिक कुशल कैसे हो सकता है? इस तरह के काम करने के लिए प्लस एसक्यूएल इंजन को अनुकूलित किया जाता है।

हो सकता है कि एसक्यूएल सीखने के लिए आपका सहकर्मी बहुत आलसी हो।

— जियोवन्नी गैल्बो
स्रोत

12

हाँ तुम्हें करना चाहिए।

और आपको प्रदर्शन के कारण C # के बजाय C ++ का उपयोग करना चाहिए। C # आलसी लोगों के लिए है।

नहीं नहीं नहीं। प्रदर्शन के कारण आपको C ++ के बजाय C का उपयोग करना चाहिए। C ++ आलसी लोगों के लिए है।

नहीं नहीं नहीं। प्रदर्शन के कारण आपको C के बजाय असेंबली का उपयोग करना चाहिए। C आलसी लोगों के लिए है।

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

— RedPain
स्रोत

1

मैंने अब तक आपके सभी उत्तरों को देखा है और वे बहुत मज़ेदार हैं। कृपया उन्हें आते रहें। या तो वह या, मैं आपके ब्लॉग की सदस्यता कहां ले सकता हूं?

— गेरी

11

"यह तकनीकी सत्य है" - इसी तरह, एक SQL डेटाबेस बेकार है: CSV फ़ाइलों का एक गुच्छा का उपयोग करके और कोड में उन्हें सहसंबंधित करके जब आप एक ही परिणाम प्राप्त कर सकते हैं, तो एक का उपयोग करने में क्या बात है? हेक, किसी भी अमूर्त आलसी लोगों के लिए है, चलो हार्डवेयर पर मशीन कोड में प्रोग्रामिंग पर वापस जाएं! ;)

इसके अलावा, उनका आश्वासन सभी में सबसे असत्य है, लेकिन सबसे महत्वपूर्ण मामले: RDBMSs, जोइन को तेज बनाने के लिए भारी अनुकूलित हैं । रिलेशनल डेटाबेस मैनेजमेंट सिस्टम, है ना?

— पिस्कॉर भवन छोड़ दिया
स्रोत

2

+1 वाक्यांश "... तकनीकी रूप से सच" बेहतर होता अगर ओपी ने पूर्ववर्ती वाक्य में unnecessaryनहीं बल्कि शब्द का इस्तेमाल किया होता useless। यह कहना कि ज्वाइन करना बेकार है, बिना किसी तकनीकी विचार के आवश्यक रूप से असत्य है। किसी भी स्थिति में, ओपी और सहकर्मी की आरडीबीएमएस की बात गलतफहमी नहीं है, यह असामान्य है: stackoverflow.com/q/5575682/47550

— पॉल ससिक

7

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

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

कृपया ध्यान दें कि मैं एसक्यूएल जॉइन से बचने के लिए एक कठिन स्टैंड नहीं ले रहा हूं।

— श्रीकांत
स्रोत

खैर, यह आपके विशिष्ट मामले में JOINs के खिलाफ तर्कसंगत तर्क की तरह लगता है। मुझे याद है कि एफबी इंजीनियरिंग ने अपने ब्लॉग पर कुछ ऐसा ही पोस्ट किया था - स्केलिंग भी उनकी प्रमुख प्राथमिकता थी। काश, केवल प्रोग्रामर के एक छोटे से% को कभी भी ऐसा करने की आवश्यकता होगी, लेकिन कई लोग सोचते हैं कि वे "क्योंकि OMG फेसबुक ऐसा करता है";)

— पिस्कॉर ने बिल्डिंग

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

— जोडरेल

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

— पिस्कोर ने भवन

5

बिना ज्वाइन के आप ऑर्डर आइटम्स को ऑर्डर से कैसे जोड़ेंगे? यह एक रिलेशनल डेटाबेस मैनेजमेंट सिस्टम का संपूर्ण बिंदु है। बिना जोड़ के कोई संबंधपरक डेटा नहीं है और आप डेटा को संसाधित करने के लिए पाठ फ़ाइलों का उपयोग कर सकते हैं।

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

— Jonh
स्रोत

5

मैं बयान के तर्क को नहीं समझता "SQL में जॉइन बेकार हैं"। क्या इस पर काम करने से पहले डेटा को फ़िल्टर और सीमित करना उपयोगी है? जैसा कि आप अन्य उत्तरदाताओं ने कहा है कि डेटाबेस इंजन क्या करते हैं, यह वही होना चाहिए जो वे अच्छे हैं।

शायद एक आलसी प्रोग्रामर उन तकनीकों से चिपकेगा जिनके साथ वे परिचित थे और गैर तकनीकी कारणों से अन्य संभावनाओं को बढ़ाते थे।

मैं इसे आपको तय करने के लिए छोड़ देता हूं।

— Jodrell
स्रोत

5

आइए एक उदाहरण पर विचार करें: इनवॉइस रिकॉर्ड के साथ एक तालिका, और इनवॉइस लाइन आइटम रिकॉर्ड के साथ संबंधित तालिका। क्लाइंट छद्म कोड पर विचार करें:

for each (invoice in invoices)
    let invoiceLines = FindLinesFor(invoice)
...

यदि आपके पास प्रत्येक 10 लाइनों के साथ 100,000 चालान हैं, तो यह कोड 1 मिलियन की तालिका से 10 चालान लाइनों को देखेगा, और यह 100,000 बार ऐसा करेगा। जैसे-जैसे टेबल का आकार बढ़ता है, चुनिंदा ऑपरेशनों की संख्या बढ़ती जाती है, और प्रत्येक चयनित ऑपरेशन की लागत बढ़ती जाती है।

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

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

खुद ऐसा करने की कल्पना करो। आपके पास छात्रों की एक वर्णमाला सूची है और सभी छात्रों की ग्रेड रिपोर्ट (प्रति कक्षा एक पृष्ठ) के साथ एक नोटबुक है। नोटबुक को छात्रों के नामों के क्रम में क्रमबद्ध किया गया है, सूची के समान क्रम में। आप आगे बढ़ना कैसे पसंद करेंगे?

सूची से एक नाम पढ़ें।
िकताबेखोलो।
छात्र का नाम खोजें।
जब तक आप अगले छात्र या अंतिम पृष्ठ तक नहीं पहुँचते तब तक पृष्ठों को मोड़ते हुए छात्र के ग्रेड पढ़ें।
नोटबुक को बंद करें।
दोहराएँ।

या:

नोटबुक को पहले पृष्ठ पर खोलें।
सूची से एक नाम पढ़ें।
नोटबुक से उस नाम के लिए कोई भी ग्रेड पढ़ें।
अंत तक पहुंचने तक 2-3 चरणों को दोहराएं
नोटबुक को बंद करें।

— phoog
स्रोत

5

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

— jcollum
स्रोत

3

वह निश्चित रूप से गलत है। हालांकि C # या Java जैसी भाषाओं में डेटा हेरफेर के निश्चित नियम हैं, लेकिन SQL की प्रकृति के कारण ही डेटाबेस में जॉइन सबसे तेज हैं।

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

C # का उपयोग करने के पेशेवरों के खेल में आते हैं जब आपको कुछ पुनरावृत्त करने की आवश्यकता होती है। यदि आपको प्रत्येक पंक्ति के लिए कुछ फ़ंक्शन करने की आवश्यकता है, तो C # के भीतर ऐसा करना तेज़ी से संभव है, अन्यथा, डेटा में शामिल होना DB में अनुकूलित है।

— माइक एम।
स्रोत

3

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

— JaCraig
स्रोत

3

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

— पीटर लॉरी
स्रोत

3

अधिकांश डेटाबेस इंजन वैसे भी आपके पीछे के दृश्यों के लिए ऐसा करेंगे; और उदाहरण के लिए MySQL में आप विशुद्ध रूप से इन-मेमोरी टेबल ( MEMORYइंजन) बना सकते हैं । डेटाबेस के बिना डेटाबेस की कार्यक्षमता को फिर से लागू करना आमतौर पर NIH के एक गंभीर मामले का संकेत है;)

— पिस्कवर ने

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

— पिस्कोवर ने

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

— बजे पीटर लॉरी

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

— मेरिटॉन

2

नहीं, न केवल डेटाबेस कोड में बेहतर तरीके से शामिल किया गया है जो तदर्थ C # / Java; लेकिन आमतौर पर कई फ़िल्टरिंग तकनीकों को लागू किया जा सकता है, जो बेहतर प्रदर्शन देता है।

— जोनास बिस्ट्रॉम
स्रोत

2

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

select t1.field1 
from table1 t1
join table2 t2 
    on t1.id = t2.id
where t1.field2 = 'test'

मान लें कि आपके पास तालिका 1 में 10 मिलियन रिकॉर्ड और तालिका 2 में 1 मिलियन रिकॉर्ड हैं। मान लें कि तालिका 1 में 9 मिलियन रिकॉर्ड कहाँ से मिलते हैं। मान लें कि उनमें से केवल 15 तालिका 2 में हैं। आप इस sql स्टेटमेंट को चला सकते हैं जो यदि ठीक से अनुक्रमित होता है तो मिलीसेकंड लेगा और केवल 1 कॉलम डेटा के साथ नेटवर्क में 15 रिकॉर्ड लौटाएगा। या आप डेटा के 2 कॉलम के साथ दस मिलियन रिकॉर्ड भेज सकते हैं और अलग से नेटवर्क में डेटा के एक कॉलम के साथ एक और 1 लाख रिकॉर्ड भेज सकते हैं और उन्हें वेब सर्वर पर जोड़ सकते हैं।

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

— HLGEM
स्रोत

2

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

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

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

तो जवाब निश्चित रूप से है: नहीं, JOINSबिल्कुल बेकार नहीं हैं!

— perdian
स्रोत

0

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

— fredt
स्रोत

0

जब तक मैंने गंभीरता से गलत नहीं समझा, सवाल में तर्क बहुत त्रुटिपूर्ण है

यदि प्रत्येक ए के लिए बी में 20 पंक्तियाँ हैं, तो ए में 1000 पंक्तियाँ 20 बी पंक्तियों में निहित हैं। बी में सिर्फ 100 पंक्तियाँ नहीं हो सकती हैं जब तक कि मैपिंग वाले 20k पंक्तियों के साथ कई-कई तालिका "एबी" न हों। ।

तो सभी जानकारी प्राप्त करने के लिए जिसके बारे में 100 बी पंक्तियों में से प्रत्येक प्रत्येक पंक्ति में आप एबी को भी मैप करते हैं। तो यह होगा:

100, 1000 और 20k पंक्तियों के 3 परिणाम सेट और एक ग्राहक शामिल हैं
20k पंक्तियों के साथ सेट किया गया एक सिंगल ए-एबी-बी परिणाम

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

किसी भी मामले में, मैं कहूंगा कि इस परिमाण के क्रॉस जॉइन का कोई उपयोग नहीं है। यह एक खराब उदाहरण है।

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

बाद का विचार:

क्लाइंट में शामिल होने के लिए लगातार वस्तुओं की आवश्यकता होती है जैसे कि डेटाटेबल्स (इन .net)। यदि आपके पास एक चपटा परिणाम है, तो इसका उपयोग डाटारीडर जैसे कुछ लाइटर के माध्यम से किया जा सकता है। उच्च मात्रा = बहुत सारे ग्राहक संसाधनों का उपयोग डेटाबेस से बचने के लिए किया जाता है।

— GBN
स्रोत