2008-12-28 3 views
5

जावा में डेटाबेस में डालने से पहले चर से बचने के लिए अनुशंसित विधि क्या है?क्या मुझे जावा में अपने सभी डेटाबेस आवेषणों के लिए तैयार किए गए स्टेटमेंट का उपयोग करना चाहिए?

जैसा कि मैं समझता हूं, मैं डेटा से बचने के लिए PreparedStatement.setString() का उपयोग कर सकता हूं, लेकिन अगर मैं एक ही प्रश्न को फिर से चलाने की योजना नहीं बना रहा हूं तो तैयार किए गए स्टेटमेंट कुछ हद तक अव्यवहारिक लगता है .. क्या इसके बिना ऐसा करने का कोई बेहतर तरीका है हर सवाल तैयार कर रहे हैं?

+0

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

उत्तर

27

हां, सब कुछ के लिए तैयार बयान का उपयोग करें।

  1. उन्हें एक बार पार्स किया जाता है।

  2. वे एसक्यूएल इंजेक्शन हमलों से प्रतिरक्षा हैं।

  3. वे एक बेहतर डिज़ाइन हैं क्योंकि आपको अपने एसक्यूएल के बारे में सोचना है और इसका उपयोग कैसे किया जाता है।

यदि आपको लगता है कि वे केवल एक बार उपयोग किए जाते हैं, तो आप बड़ी तस्वीर को नहीं देख रहे हैं। कुछ दिन, आपका डेटा या आपका आवेदन बदल जाएगा।


संपादित करें।

तैयार वक्तव्य आपको अपने एसक्यूएल के बारे में क्यों सोचते हैं?

  • आप एक स्ट्रिंग इकट्ठा (या बस पाठ की एक शाब्दिक ब्लॉक निष्पादित) आप एक नया PreparedStatement वस्तु बनाने नहीं होती हैं। आप बस एसक्यूएल निष्पादित कर रहे हैं - इसे बहुत ही आकस्मिक तरीके से किया जा सकता है।

  • जब आपको PreparedStatement बनाना (और सहेजना) बनाना है, तो आपको ज़िम्मेदारी आवंटन, encapsulation के बारे में कुछ और सोचना होगा। किसी भी एसक्यूएल प्रसंस्करण करने से पहले एक बयान की तैयारी एक राज्यव्यापी घटना है।

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

तैयार बयानों के साथ, डेटाबेस पहुंच कम आकस्मिक, अधिक जानबूझकर है।

+0

मैं प्रतिरक्षा नहीं कहूंगा, लेकिन संरक्षित। – Milhous

+0

@ मिल्हस। सहमत नहीं हैं। बाध्य चर और स्थिर एसक्यूएल पाठ का उपयोग कर तैयार बयान प्रतिरक्षा हैं। पूरी तरह से। –

+0

आप मान रहे हैं कि बाध्यकारी में इसमें कोई बग नहीं है। मुझे गलत मत समझो, मैं जो भी उपयोग करता हूं वह तैयार बयान हैं। – Milhous

4

एक कथन तैयार करना महंगा नहीं है। यह अधिकांश विकल्पों की तुलना में सुरक्षित है।

9

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

बिंदु यह है: तैयार बयान के साथ, यह असंभव SQL इंजेक्शन योग्य कथन बनाने के लिए है। कस्टम से बचने के साथ, यह संभव है। पसंद स्पष्ट है।

+0

"स्ट्रिंग कॉन्सटेनेशन का उपयोग करके स्वयं को कभी भी SQL क्वेरी का निर्माण न करें", संभवतः आप रनटाइम वैरिएबल के बाध्यकारी के बारे में बात कर रहे हैं, एसक्यूएल स्टेटमेंट का निर्माण नहीं? ऐसे कई मामले हैं जब एक क्वेरी के डीएमएल को रनटाइम पर बदलना पड़ता है, इस मामले में स्ट्रिंग्स स्ट्रिंग्स ठीक लगता है –

3

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

3

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

+0

पूरी तरह से इस से सहमत हैं। वसंत इसे इतना आसान बनाता है। यदि आप लेनदेन संबंधी सामान का उपयोग करते हैं तो यह परीक्षण को बहुत आसान बनाता है। – Fortyrunner

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

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