SQLCommand को पैरामीटर पास करने का सबसे अच्छा तरीका क्या है?

SQLCommand को पैरामीटर पास करने का सबसे अच्छा तरीका क्या है? तुम कर सकते हो:

cmd.Parameters.Add("@Name", SqlDbType.VarChar, 20).Value = "Bob";

या

cmd.Parameters.Add("@Name", SqlDbType.VarChar).Value = "Bob";

या

cmd.Parameters.Add("@Name").Value = "Bob";

It seems like the first one might be somehow "better" either perfयाmance-wise या errया checking-wise. But I would like to know mयाe definitively.

0

5 उत्तर

वहां क्या हो रहा है?

आप जोड़ें के कई ओवरलोड के लिए पैरामीटर सूचियों को उद्धृत करते हैं। ये सुविधा विधियां हैं जो SqlParameter कक्षा के लिए सीधे कन्स्ट्रक्टर ओवरलोड से मेल खाते हैं। वे अनिवार्य रूप से पैरामीटर ऑब्जेक्ट का निर्माण करते हैं जो कि कन्स्ट्रक्टर के पास आपके द्वारा बुलाए गए सुविधा विधि के समान हस्ताक्षर है, और फिर SqlParameterCollection.Add (SqlParameter) को कॉल करें:

SqlParameter foo = new SqlParameter(parameterName, dbType, size);
this.Add(foo);

AddWithValue is similar but takes convenience even further, also setting the value. However, it was actually introduced to resolve a framework flaw. To quote MSDN,

जोड़ें का ओवरलोड जो एक लेता है   स्ट्रिंग और ऑब्जेक्ट को बहिष्कृत किया गया था   के साथ संभावित अस्पष्टता के कारण    SqlParameterCollection.Add अधिभार जोड़ें   जो स्ट्रिंग और SqlDbType लेता है   गणना मूल्य जहां गुजर रहा है   स्ट्रिंग के साथ पूर्णांक हो सकता है   या तो होने के रूप में व्याख्या की   पैरामीटर मान या संबंधित   <कोड> SqlDbType मान। AddWithValue का उपयोग करें   जब भी आप एक पैरामीटर जोड़ना चाहते हैं   इसका नाम और मूल्य निर्दिष्ट करके।

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

मुझे क्या करना चाहिए?

निम्नलिखित ध्यान दें (एमएसडीएन से)

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

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

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

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


2008 बहुत समय पहले था

सालों से मैंने यह लिखा है, दुनिया बदल गई है। नई तरह की तारीखें हैं, और ऐसी समस्या भी है जो मेरे दिमाग को पार नहीं कर लेती है जब तक कि तारीखों के साथ हालिया समस्या ने मुझे विस्तार के प्रभावों के बारे में सोचा नहीं।

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

This can apply to strings: NVARCHAR is wider than VARCHAR, so you can assign a VARCHAR to an NVARCHAR but going the other way requires a cast. Comparison works because the VARCHAR implicitly widens to NVARCHAR, but this will interfere with the use of indexes!

सी # तार यूनिकोड हैं, इसलिए AddWithValue एक NVARCHAR पैरामीटर उत्पन्न करेगा। दूसरी तरफ, VARCHAR कॉलम मान तुलना के लिए एनवीएआरएआरएआर तक फैले हुए हैं। यह क्वेरी निष्पादन को रोकता नहीं है लेकिन यह इंडेक्स को इस्तेमाल होने से रोकता है। ये गलत है।

आप इसके बारे में क्या कर सकते हैं? आपके पास दो संभावित समाधान हैं।

  • स्पष्ट रूप से पैरामीटर टाइप करें। इसका मतलब अब AddWithValue
  • नहीं है
  • सभी स्ट्रिंग कॉलम प्रकारों को NVARCHAR में बदलें।

VARCHAR डुबकी शायद सबसे अच्छा विचार है। अनुमानित परिणामों के साथ यह एक साधारण बदलाव है और यह आपके स्थानीयकरण की कहानी में सुधार करता है। हालांकि, आपके पास यह विकल्प नहीं हो सकता है।

इन दिनों मैं बहुत सी प्रत्यक्ष ADO.NET नहीं करता हूं। Linq2Sql अब मेरी पसंद का हथियार है, और इस अद्यतन को लिखने के कार्य ने मुझे आश्चर्यचकित कर दिया है कि यह इस समस्या को कैसे संभालता है। मेरे पास वचरर के अपने डेटाबेस को शुद्ध करने की अचानक, ज्वलंत इच्छा है।

0
जोड़ा

मैं आपके विकल्प 1 का उपयोग करता था:

cmd.Parameters.Add ("@ name", SqlDbType.VarChar, 20)। वैल्यू = "बॉब";

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

0
जोड़ा

आप AddWithValue() का भी उपयोग कर सकते हैं, लेकिन गलत अंतर्निहित प्रकार रूपांतरण की संभावना से अवगत रहें।

cmd.Parameters.AddWithValue("@Name", "Bob");
0
जोड़ा
जोड़ा लेखक Joel Coehoorn, स्रोत

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

0
जोड़ा

मैं निश्चित रूप से # 1 कहूंगा। लेकिन, हालांकि माइक्रोसॉफ्ट इसे एंटरप्राइज़ लाइब्रेरी में डेटा एक्सेस एप्लिकेशन ब्लॉक में करता है, एसक्यूएल सर्वर के लिए सबसे अच्छा है, esp:

http://msdn.microsoft.com/en-us/library/dd203144। aspx

0
जोड़ा
मैं # 1 का भी उपयोग करता हूं क्योंकि cmd.Prepare() को परिवर्तनीय आकार डेटा प्रकारों की लंबाई की आवश्यकता होती है जैसे nvarchar इत्यादि।
जोड़ा लेखक J Pollack, स्रोत