क्या आप इस सरल एसक्यूएल को फिर से काम के लिए भेज देंगे?

Question

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

वेब पेज गतिशील रूप से दर्ज पैरामीटर के आधार पर निष्पादित करने के लिए SQL का निर्माण करता है। उदाहरण के लिए, उपयोगकर्ता द्वारा दर्ज करता है, तो "1" के लिए "बिजनेस यूनिट" हम इस तरह एक एसक्यूएल का निर्माण:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1' 
--AND other criteria based on the input params 

मैंने पाया कि जहां उपयोगकर्ता किसी BUSINESS_UNIT निर्दिष्ट नहीं करता निम्न क्वेरी

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%' 
--AND other criteria based on the input params 

निर्माण किया है

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

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

Ty

---

अद्यतन:

मैं एक Oracle डेटाबेस का उपयोग कर रहा हूँ।

मेरी धारणा यह है कि ओरेकल इस स्थिति को हटाकर "पसंद"% अनुकूलित नहीं करता है और इसे छोड़कर कम कुशल होता है। क्या कोई पुष्टि कर सकता है?

Answer 1

हालांकि यह काफी अक्षम है, लेकिन मैंने इसे SQL सर्वर में अभी परीक्षण किया है, और क्वेरी ऑप्टिमाइज़र इसे फ़िल्टर करने के लिए पर्याप्त स्मार्ट था।

दूसरे शब्दों में,

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%' 

और

SELECT * FROM FACT 

ठीक उसी क्वेरी योजना उत्पन्न। इसलिए कोई प्रदर्शन अंतर नहीं होना चाहिए (आपके डीबी इंजन के आधार पर मुझे लगता है), हालांकि यह तरह का मैला दिखता है।

इससे आपको वापस भेजने या अस्वीकार करने के आपके निर्णय को प्रभावित हो सकता है। व्यक्तिगत रूप से मैं शायद करता हूं, लेकिन यदि आप पहले से ही बादल के नीचे हैं तो यह संभवतः कम से कम प्रदर्शन के संदर्भ में आप आराम कर सकते हैं।

Answer 2

मैं इसे वापस भेजूंगा और मुझे सवाल पसंद है।

सभी कोड समीक्षा कुछ हद तक व्यक्तिपरक है। मानदंड कई कारकों पर आधारित होना चाहिए।

• क्या यह काम करता है।

• यह प्रदर्शन, रख-रखाव, प्रयोज्य, और scalability

की उचित अपेक्षाओं को पूरा करता है जब मैं इस विशेष निर्माण परीक्षण नहीं किया - मुझे लगता है (जैसा कि आप करते हैं) के लिए इस कोड को भयानक काम करेंगे आपका एसक्यूएल सर्वर इस प्रकार प्रदर्शन और मापनीयता को प्रश्न में बुलाया जाता है। तो मुझे लगता है कि यह तालिका की एक पूरी स्कैन के लिए मजबूर होगा ...

, हाँ, मुझे लगता है कि प्रश्न पर फिर से काम किया है की कोशिश करेंगे -

Answer 3

कि क्वेरी, BUSINESS_UNIT LIKE '%' साथ काफी कुशल दिखता है नहीं , इस तरह की स्थिति को उचित तरीके से निपटने के लिए - या, कम से कम, मैं उस समस्या को हमारे बग-ट्रैकरके माध्यम से रिपोर्ट करूंगा (प्राथमिकता के बारे में सुनिश्चित नहीं हूं कि मैं असाइन करूंगा, लेकिन फिर भी, समस्या होगी कहीं लॉग इन किया गया है, और कोई इसे किसी दिन सही करेगा, जब कोई उच्च प्राथमिकता समस्या से निपटने में कोई समस्या नहीं है)।

Answer 4

लेखक एक डमी स्टेटमेंट चाहता था ताकि वह बाद के बयान में "और" संलग्न हो सके। इसे बेहतर "नो-ऑप" कथन में बदलना जैसे 1 == 1 मदद करेगा। या वे थोड़ा और काम कर सकते हैं और समझदारी से "कहाँ" डालें।

Answer 5

चयन * एक लाल झंडा है। क्वेरी के लिए कॉलम सूची निर्दिष्ट करें।

Answer 6

दो प्रश्नों पूरी तरह से अलग कर रहे हैं (एक परिणाम सेट की दृष्टि से)

SELECT * FROM FACT; 

और

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%'; 

पहले अगर वहाँ NULL हैं सभी पंक्तियों, दूसरी वापस आ जाएगी, मूल्य उन पंक्तियों को वापस नहीं किया जाएगा क्योंकि NULL की तुलना में कुछ भी NULL है और इसलिए भविष्यवाणी को पूरा नहीं करता है। ओरेकल में यह काम करेगा।

Answer 7

मैं सवाल क्यों बाँध चर इस्तेमाल नहीं किया जा रहा है (जब तक वहाँ विशेष मामलों में एक अच्छा कारण है):

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1' 

क्यों यह नहीं है:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = :bu