2010-08-02 28 views
5

संभव डुप्लिकेट:
Which is faster/best? SELECT * or SELECT column1, colum2, column3, etc.एसक्यूएल: का प्रयोग करें *

यह बुरा व्यवहार Select * उपयोग करने के लिए है?

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

+0

यदि आपको पूर्ण विवरण की आवश्यकता है, तो 'select *' का उपयोग करें - विशेष रूप से यदि आपको भविष्य के विस्तार कॉलम की आवश्यकता है जिन्हें आप नाम नहीं जानते हैं। –

+2

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

उत्तर

1

हां, यह खराब अभ्यास समझा जाता है।

स्पष्ट कॉलम सूची निर्दिष्ट करना बेहतर है, खासकर यदि तालिका में कई कॉलम हैं और आपको केवल उनमें से कुछ की आवश्यकता है।

0

भले ही आप बल्कि फिर उन्हें निर्दिष्ट '*' चुनें

1

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

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

5

यह बुरा अभ्यास है।

यदि आपकी स्कीमा सड़क के नीचे बदल जाती है, तो कॉलिंग एप्लिकेशन को अधिक फ़ील्ड मिल सकते हैं इससे पता चलता है कि क्या करना है।

इसके अलावा, आपको आवश्यकता से अधिक जानकारी मिल रही है, जो प्रदर्शन को प्रभावित करती है।

इसके अलावा, यह भी दर्शाता है कि आप नहीं जानते कि कॉलम क्या हैं।

+0

मैंने लगभग एक लाभ के रूप में देखा। मुझे अपनी मेज पर एक फ़ील्ड जोड़ना है और अब मुझे नए क्षेत्र के लिए एसक्यूएल क्वेरी बदलने के लिए कोड में जाना है, बनाम चयन * कोई बदलाव नहीं करना होगा। – mint

+1

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

+0

@now, यह एक बड़ा नुकसान है, आप उस उपयोगकर्ता को जानकारी का पर्दाफाश कर सकते हैं जिसे आप नहीं देखना चाहते हैं। इसके अलावा यह कुछ तोड़ सकता है अगर कुछ यो आप कॉलम में कॉलम को पुनर्व्यवस्थित करने का निर्णय लेते हैं (हां ऐसे बेवकूफ हैं जो यह करते हैं) और अब आप अंतिम नाम से डेटा को पहले नाम कॉलम में जोड़ रहे हैं और इसके विपरीत। सेल्ट * बस खराब है। – HLGEM

4

का उपयोग SELECT * दो कारणों के लिए बुरा व्यवहार है:

  • यह अतिरिक्त कॉलम है कि आप की जरूरत नहीं है लौट सकते हैं बैंडविड्थ
  • अगर किसी को किसी स्तंभ
कहते हैं यह अपने कोड तोड़ सकते हैं बर्बाद कर
2

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

+0

मैंने संग्रहित प्रक्रियाओं में चयन * का उपयोग करके कॉलम के 'बेकिंग' के बारे में कभी नहीं सुना था ... हालांकि उल्लेख किया गया। – mint

1

जब आप SELECT * का उपयोग करते हैं, तो आप संभावित रखरखाव उत्पादकता के लिए तत्काल उत्पादकता (एक प्रश्न तेजी से लिखना) का व्यापार करना चुनते हैं (क्या आपकी अंतर्निहित क्वेरी बदलनी चाहिए और इस प्रकार निर्भर कोड/प्रश्नों को तोड़ना चाहिए)। अभ्यास की "बुरी नस्ल" एक जोखिम प्रबंधन गतिविधि है।

संबंधित मुद्दे