नहीं।
यह या तो एक लंबे समय से पहले सच था (और अब नहीं है, कम से कम एसक्यूएल सर्वर 2000 के बाद से), या यह कभी भी सच नहीं था और आपका डीबीए सिर्फ निम्नलिखित के साथ उसकी सिफारिश को भ्रमित करता है :
संग्रहीत कार्यविधि की शुरुआत में अस्थायी तालिकाओं के लिए सभी डीडीएल बयानों (जैसे इंडेक्स बनाने) को एक साथ समूहित करना महत्वपूर्ण है। इन DDL कथनों को एक साथ रखकर स्कीमा परिवर्तन के कारण होने वाले अनावश्यक संकलन से बचा जा सकता है।
आप इस पृष्ठ पर इस अनुशंसा के पीछे तर्क का एक और स्पष्टीकरण पा सकते हैं ।
यदि हम इस Microsoft KB पर एक नज़र डालें , तो हम देखते हैं कि संग्रहीत प्रक्रिया का कारण recompile निम्नलिखित में से एक हो सकता है (SQL Server 2005+):
- स्कीम्स बदल गए।
- आंकड़े बदल गए।
- पुनः संयोजक DNR।
- सेट का विकल्प बदल गया।
- टेम्प टेबल बदली।
- रिमोट की पंक्तियाँ बदलीं।
- ब्राउज़ के लिए परमिट बदल गए।
- क्वेरी अधिसूचना वातावरण बदल गया।
- MPI दृश्य बदला
- कर्सर विकल्प बदल गए।
- Recompile विकल्प के साथ।
एक चर की घोषणा - यहां तक कि एक तालिका चर (यानी @table_variable) - इनमें से किसी भी घटना को ट्रिगर नहीं किया जा सकता है, जाहिर है, क्योंकि एक चर घोषित करने से डीडीएल की गिनती नहीं होती है । एक चर (यहां तक कि एक तालिका चर) एक अस्थायी वस्तु है जो आपके टी-एसक्यूएल प्रोग्रामिंग के लिए विशेष रूप से उपयोग की जाती है। यही कारण है कि टेबल चर को कोई आँकड़े नहीं मिलते हैं और वे लेनदेन से बाध्य नहीं होते हैं । एक चर (तालिका या नहीं) की घोषणा एक खरीद recompile ट्रिगर नहीं कर सकते।
एक अस्थायी तालिका (यानी बनाना #temp_table) या एक सूचकांक है, तथापि, है DDL डेटाबेस के भौतिक परिभाषा प्रभावित करता है। टेंप टेबल और इंडेक्स सांख्यिकी और ट्रांजेक्शनल कंट्रोल के साथ "वास्तविक" ऑब्जेक्ट हैं, इसलिए उन्हें बनाने से ऊपर की सूची में किसी भी घटना 1, 2 या 5 में आग लग सकती है और इस तरह एक खरीद recompile को ट्रिगर किया जा सकता है।