क्या आपने कभी एक क्वेरी का सामना किया है कि SQL सर्वर निष्पादित नहीं कर सका क्योंकि यह बहुत सी तालिकाओं का संदर्भ देता है?

मैं उस क्वेरी को देखना चाहता हूं, लेकिन मुझे लगता है कि यह किसी प्रकार के इटरेटर के साथ कुछ समस्या है, और जब भी मैं इसे किसी भी परिस्थिति के बारे में नहीं सोच सकता, तो मुझे लगता है कि यह खराब है / केस / कर्सर या एक टन खराब कार्यान्वित विचार।

क्वेरी पोस्ट करें: डी

इसके अलावा मुझे लगता है कि संभावित समस्याओं में से एक को नाम / मूल्य सारणी का एक टन (200+ पढ़ना) हो सकता है जो एक लुकअप टेबल में घुलन सकता है।

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

SQL सर्वर 2005 के लिए, मैं तालिका चर का उपयोग करने और आंशिक रूप से डेटा को बनाने के साथ अनुशंसा करता हूं।

ऐसा करने के लिए, एक टेबल वेरिएबल बनाएं जो आपके अंतिम परिणाम सेट का प्रतिनिधित्व करता है जिसे आप उपयोगकर्ता को भेजना चाहते हैं।

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

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

एक बार पूरा होने के बाद, आप अपने टेबल वैरिएबल से एक साधारण चयन * कर सकते हैं और इस परिणाम को उपयोगकर्ता को सेट कर सकते हैं।

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

I have never come across this kind of situation, and to be honest the idea of referencing > 256 tables in a query fils me with a mortal dread.

आपका पहला प्रश्न शायद "इतने सारे क्यों" हो सकता है, इसके बाद "मैं किस जानकारी के बिट्स नहीं की आवश्यकता है?" मुझे चिंता होगी कि ऐसी क्वेरी से लौटाए जाने वाले डेटा की मात्रा बहुत ही गंभीर रूप से आवेदन के प्रदर्शन को प्रभावित करेगी।

ऐसा तब होता है जब SQL Server 2000 पर चल रहे डायनेमिक्स सीआरएम इंस्टॉलेशन के लिए रिपोर्टिंग सेवा रिपोर्ट लिखते हैं। सीआरएम की अच्छी तरह से सामान्यीकृत डेटा स्कीमा है जिसके परिणामस्वरूप बहुत सारे शामिल होते हैं। वास्तव में एक हॉटफिक्स है जो 256 से 260 तक की सीमा तक बढ़ जाएगा: http://support.microsoft .com / kb / 818406 (हमने हमेशा SQL सर्वर टीम के हिस्से पर यह एक बड़ा मजाक सोचा)।

डिली-ओ के रूप में समाधान, उपयुक्त "सब-जॉइन" (अधिमानतः उन लोगों को जिन्हें कई बार उपयोग किया जाता है) की पहचान करना है और उन्हें अस्थायी-सारणी चरों में कारक बनाना है जिन्हें आप अपने मुख्य जुड़ने में उपयोग करते हैं। यह एक प्रमुख पीआईए है और अक्सर प्रदर्शन को मारता है। मुझे आपके लिये खेद है।

@ केविन, प्यार है कि टी - यह सब कहते हैं :-)।

मुझे यह वही समस्या थी ... मेरा विकास बॉक्स SQL ​​सर्वर 2008 चलाता है (दृश्य ठीक काम करता है) लेकिन उत्पादन पर (SQL सर्वर 2005 के साथ) दृश्य नहीं था। मैंने त्रुटि को फेंकने वाले दृश्य में क्वेरी के हिस्से के रूप में नए विचारों का उपयोग करके इस सीमा से बचने के लिए विचारों को समाप्त कर दिया।

तार्किक निष्पादन पर विचार करने के मूर्खतापूर्ण तरह एक ही है ...

जब मैं एक दृश्य बनाना चाहता था तो SQL Server 2005 (2008 में काम किया) में एक ही समस्या थी। मैंने एक दृश्य के बजाय संग्रहीत प्रक्रिया बनाकर इस मुद्दे को हल किया।