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

क्या आपने कभी किसी त्रुटि संदेश को देखा है?

- SQL सर्वर 2000

     

दृश्य या फ़ंक्शन रिज़ॉल्यूशन के लिए सहायक तालिका आवंटित नहीं किया जा सका।
  किसी क्वेरी (256) में तालिकाओं की अधिकतम संख्या पार हो गई थी।

     

- SQL सर्वर 2005

     

क्वेरी में बहुत सारे टेबल नाम। अधिकतम स्वीकार्य 256 है।

यदि हां, तो आपने क्या किया है?

छोड़ दिया? ग्राहक को उनकी मांगों को सरल बनाने के लिए आश्वस्त किया? डेटाबेस को denormalized?


@ (हर कोई मुझे प्रश्न पोस्ट करना चाहता है):

  1. मुझे यकीन नहीं है कि क्या मैं उत्तर संपादन विंडो में 70 किलोबाइट कोड पेस्ट कर सकता हूं।
  2. यहां तक ​​कि यदि मैं यह कर सकता हूं तो यह मदद नहीं करेगा क्योंकि 70 किलोबाइट कोड 20 या 30 विचारों का संदर्भ देगा जो मुझे पोस्ट करना होगा क्योंकि अन्यथा कोड अर्थहीन होगा।

मैं ऐसा नहीं करना चाहता जैसे मैं यहां घमंड कर रहा हूं लेकिन समस्या प्रश्नों में नहीं है। प्रश्न इष्टतम (या कम से कम लगभग इष्टतम) हैं। मैंने उन्हें अनुकूलित करने के अनगिनत घंटे बिताए हैं, हर कॉलम और हर एक टेबल को हटाया जा सकता है जिसे हटाया जा सकता है। ऐसी रिपोर्ट की कल्पना करें जिसमें 200 या 300 कॉलम हैं जिन्हें एकल चयन कथन से भरना होगा (क्योंकि इस तरह यह कुछ साल पहले बनाया गया था जब यह अभी भी एक छोटी रिपोर्ट थी)।

0
जोड़ा संपादित
विचारों: 2
दृश्य मदद नहीं करेंगे। दृश्यों में उपयोग की जाने वाली सारणी भी सीमा की ओर गिनती हैं।
जोड़ा लेखक Marek Grzenkowicz, स्रोत
क्या आप SQL Server 2000 SP3 का उपयोग कर रहे हैं?
जोड़ा लेखक Stu, स्रोत
क्या आप संभवतः कुछ विचार बना सकते हैं?
जोड़ा लेखक Calvin Allen, स्रोत

8 उत्तर

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

0
जोड़ा
किसी भी तरह का कोई इटरेटर नहीं। बस एक ही चयन कथन।
जोड़ा लेखक Marek Grzenkowicz, स्रोत

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

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

0
जोड़ा

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

0
जोड़ा

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

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

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

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

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

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

0
जोड़ा

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.

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

0
जोड़ा
एक ऐसे ग्राहक की कल्पना करें जो अपने स्टोर में वस्तुओं की एक सूची (ग्रिड में) वास्तव में जानकारी के बहुत से संबंधित टुकड़ों के साथ देखना चाहता है (उदाहरण के लिए प्रत्येक आइटम का पहला आदेश, अंतिम आदेश के बारे में, पहली डिलीवरी के बारे में, अंतिम वितरण के बारे में, ग्राहकों को जो इसे खरीदते हैं, डिलीवरी की लागत के बारे में ...)। मेरा विश्वास करो, यह संभव है, मैंने इसे देखा है। और मुझे इसका सामना करना पड़ा। :) हां, ऐसी परिस्थितियों में प्रदर्शन पर असर गंभीर हो सकता है।
जोड़ा लेखक Marek Grzenkowicz, स्रोत

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

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

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

0
जोड़ा

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

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

0
जोड़ा
यह अजीब बात है कि इससे मदद मिली - जहां तक ​​मुझे पता है, विचारों में उपयोग की जाने वाली टेबल सीमा की ओर गिनती है। क्या आप अनुक्रमित विचारों का उपयोग कर रहे हैं?
जोड़ा लेखक Marek Grzenkowicz, स्रोत

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

0
जोड़ा