2013-02-12 47 views
5

हमारे पास orders डेटा है और हमें SQL का उपयोग करके Weekly - Custom date Range of 7 Days रिपोर्ट जेनरेट करने की आवश्यकता है। रिपोर्ट ऑर्डर के साप्ताहिक count प्रदर्शित करेगी। उपयोगकर्ता End Date का चयन करेगा और हमें उस तिथि के आधार पर 12 डेटरेंज इकाइयां बनाने की आवश्यकता है। उदाहरण के लिए उपयोगकर्ता का चयन करता है 1/24/2013 हम 12 अंक/इकाइयों की जरूरत के रूप में:क्या यह रिपोर्ट के लिए एसक्यूएल लिखने का सबसे अच्छा तरीका है?

Point12 = End Date - 7 Days 
Point11 = End Date - 14 Days 
Point10 = End Date - 21 Days 
Point9 = End Date - 28 Days 
. 
. 
Point1 = End Date - X Days 

हमारा समाधान:

हम एक अस्थायी तालिका बनाने के लिए योजना बना रहे हैं कि तालिका 12 पंक्तियाँ होगा। प्रत्येक पंक्ति की तरह डेटा होगा (हम StartDate और EndDate प्रत्येक प्वाइंट के लिए गणना करेगा):

Point StartDate   EndDate  TotalOrders 
Point12 2013-01-24   2013-01-30 
Point11 2013-01-17   2013-01-23 

इस के बाद हम प्रत्येक पंक्ति के लिए आदेश की count मिल जाएगा।

क्या यह इस समस्या का एक अच्छा समाधान है या इसे अनुकूलित किया जा सकता है?

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

साप्ताहिक DATERANGE एक Custom date Range of 7 Days हो जाएगा।

enter image description here

+0

@EdHeal: मैं इसे अपने आप कर सकता हूं। लेकिन मैं सिर्फ यह जानना चाहता हूं कि मैं इसे सबसे अच्छे तरीके से कर रहा हूं। इस परिदृश्य में –

+1

आपको बेहतर प्रदर्शन के लिए तालिका चर का उपयोग करना चाहिए। आप इस आलेख को अंतर के बारे में पढ़ सकते हैं: http://www.sql-server-performance.com/2007/temp-tables-vs-variables/ –

+0

आप प्रत्येक पंक्ति के लिए 'गिनती' कैसे प्राप्त कर रहे हैं? – msmucker0527

उत्तर

-1

क्यों सिर्फ कारक समूहन के रूप में सप्ताह का उपयोग नहीं करते?

SELECT 
WEEKOFYEAR(`date`) AS point, 
SUM(orders) AS order 
FROM `tablename` 
WHERE `date` BETWEEN `startdate` AND `enddate` 
GROUP BY point 
1

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

मुख्य प्रश्न से पहले एक अलग चरण के रूप में आवश्यक पंक्तियों (तालिका चर/अस्थायी तालिका में) उत्पन्न करने के बजाय मुख्य क्वेरी के हिस्से के रूप में सीटीई में 12 पंक्तियां उत्पन्न करने का एक वैकल्पिक दृष्टिकोण होगा। यह आवश्यक चरणों की कुल संख्या को कम करेगा, लेकिन मुख्य क्वेरी को थोड़ा और जटिल बना देगा।

+0

सलाह के लिए क्या तर्क है "मैं एक अस्थायी तालिका के बजाय तालिका चर का उपयोग करने का सुझाव देता हूं।" मैं अनिवार्य रूप से असहमत नहीं हूं लेकिन आपको वह लाभ बता देना चाहिए जो आपको विश्वास होगा। –

+0

यह एक मिथक है। दोनों तालिका चर और 'temp' टेबल 'tempdb' में आयोजित किए जाते हैं और उनमें से दोनों को छोटी तालिका के लिए स्मृति में सभी पृष्ठ होने की संभावना होगी। –

+0

यह एमएसडीएन आलेख देखें: http://msdn.microsoft.com/en-us/library/ms175010.aspx –