प्रॉम्प्ट और लागू संदर्भ
PostgreSQL का उपयोग करके, Q2 2026 के लिए प्रत्येक कैटेगरी में शीर्ष तीन अलग-अलग उत्पाद-राजस्व स्तर प्राप्त करें, जिसमें तीसरे स्तर पर टाई हुए प्रत्येक उत्पाद को शामिल किया गया हो। डेटा अनुबंध बताएं, SQL लिखें, और समझाएं कि ROW_NUMBER, RANK, और DENSE_RANK अलग-अलग परिणाम क्यों देते हैं।
स्कीमा इस प्रकार है:
orders( order_id bigint primary key, ordered_at timestamptz, status text )
order_items( order_id bigint, category_id bigint, product_id bigint, quantity integer, unit_price numeric(12, 2) )
इस सहमत अनुबंध का उपयोग करें: केवल COMPLETED ऑर्डरों की गणना करें; तिमाही को UTC हाफ-ओपन इंटरवल [2026-04-01, 2026-07-01) के रूप में परिभाषित करें; उत्पाद राजस्व पात्र लाइन आइटम्स पर quantity * unit_price का योग है; रिफंड दिए गए मॉडल से बाहर हैं; और "शीर्ष तीन" का अर्थ प्रति कैटेगरी तीन उच्चतम अलग-अलग राजस्व स्तर (distinct revenue levels) है, इसलिए तीसरे स्तर पर टाई हुए प्रत्येक उत्पाद को वापस किया जाना चाहिए। बिना किसी पात्र बिक्री वाले उत्पाद मौजूद नहीं होंगे, और तीन से कम स्तरों वाली कैटेगरी अपने सभी उपलब्ध स्तरों को लौटाती है।
यह मध्यम-कठिनाई वाला प्रश्न डेटा एनालिस्ट, डेटा इंजीनियर और बैकएंड भूमिकाओं के लिए उपयुक्त है जिनमें एनालिटिकल SQL की आवश्यकता होती है। 2026 की सार्वजनिक SQL इंटरव्यू सामग्रियां अभी भी टॉप-N-प्रति-ग्रुप, विंडो फ़ंक्शंस और टाई व्यवहार को स्पष्ट अभ्यास के रूप में प्रस्तुत करती हैं। कोई सत्यापन योग्य कंपनी एट्रिब्यूशन नहीं है, इसलिए इसे एक प्रतिनिधि SQL इंटरव्यू प्रश्न माना जाता है।
इंटरव्यूअर क्या मूल्यांकन करता है
पहला संकेत यह है कि क्या आप आउटपुट ग्रेन बताते हैं। एक order_items पंक्ति एक लाइन आइटम है, लेकिन लक्षित परिणाम प्रति कैटेगरी-उत्पाद जोड़ी एक पंक्ति है। रॉ लाइन आइटम्स की रैंकिंग करने से एक उत्पाद को कई स्थान मिल जाते हैं। सिंटैक्स की दृष्टि से मान्य SQL भी गलत व्यावसायिक प्रश्न का उत्तर दे सकता है।
दूसरा संकेत यह है कि क्या आप "शीर्ष तीन" को स्पष्ट टाई सिमेंटिक्स में अनुवादित करते हैं। ROW_NUMBER, RANK, और DENSE_RANK सभी एक कैटेगरी के भीतर पंक्तियों को क्रमबद्ध कर सकते हैं, लेकिन वे अलग-अलग प्रश्नों के उत्तर देते हैं। एक मजबूत उम्मीदवार पहले पूछता है कि क्या परिणाम में ठीक तीन पंक्तियां, कॉम्पिटिशन रैंक, या तीन अलग-अलग राजस्व स्तर चाहिए।
तीसरा संकेत SQL के लॉजिकल इवैल्यूएशन ऑर्डर का ज्ञान है। विंडो फ़ंक्शन WHERE, GROUP BY, HAVING, और सामान्य एग्रीगेशन के बाद चलते हैं। पहले उत्पाद राजस्व को एग्रीगेट करें, अगले स्तर पर इसे रैंक करें, और बाहरी क्वेरी में रैंक को फ़िल्टर करें। PostgreSQL उसी क्वेरी स्तर के WHERE क्लॉज में विंडो उपनाम (alias) का उपयोग नहीं कर सकता है।
अंतिम संकेत सत्यापन योग्यता और रखरखाव है। एक मजबूत उत्तर समय सीमा, पात्र स्थिति, मुद्रा प्रकार, निर्धारक प्रस्तुति क्रम और परीक्षण फिक्सचर को परिभाषित करता है। बड़े पैमाने पर, यह रैंकिंग चरण में प्रवेश करने वाली पंक्तियों को पहले कम करता है, बजाय इसके कि असमर्थित समाधान के रूप में "इंडेक्स जोड़ें" की पेशकश की जाए।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- क्या “शीर्ष तीन” का अर्थ तीन पंक्तियाँ, तीन कॉम्पिटिशन पोजीशन, या तीन अलग-अलग मान हैं? तीन पंक्तियों के लिए
ROW_NUMBER, कॉम्पिटिशन रैंकिंग के लिएRANK, और इस आवश्यकता के लिएDENSE_RANKका उपयोग करें: टाई सुरक्षित रखते हुए तीन अलग-अलग राजस्व स्तर। - कौन सा ईवेंट और समय क्षेत्र राजस्व को एक अवधि में असाइन करता है? ऑर्डर, भुगतान, पूर्णता और रिफंड के समय अलग-अलग रिपोर्ट तैयार करते हैं। यह प्रॉम्प्ट UTC में
orders.ordered_atऔर गैर-अतिव्यापी (non-overlapping) हाफ-ओपन इंटरवल का उपयोग करता है। - कौन से स्टेटस पात्र हैं? रद्द किए गए, परीक्षण, या विफल ऑर्डरों को शामिल करने से राजस्व बढ़ जाता है। यह अनुबंध केवल
COMPLETEDकी गणना करता है। - रिफंड, छूट, कर और मुद्राएं कहां हैं? दिए गए मॉडल में केवल मात्रा और लेनदेन इकाई मूल्य शामिल हैं। यदि रिफंड तालिका या कई मुद्राएं जोड़ी जाती हैं, तो रैंकिंग से पहले शुद्ध राजस्व की गणना करें या एक मुद्रा में परिवर्तित करें।
- क्या एक उत्पाद कई श्रेणियों से संबंधित हो सकता है? यह क्वेरी लाइन आइटम पर
(category_id, product_id)को फैक्ट की (fact key) मानती है। आज के उत्पाद डायमेंशन को जोड़ने से ऐतिहासिक श्रेणी एट्रिब्यूशन फिर से लिखा जा सकता है; जब वह इतिहास मायने रखता है तो ऑर्डर-टाइम स्नैपशॉट या प्रभावी-दिनांकित (effective-dated) डायमेंशन का उपयोग करें। - क्या शून्य-बिक्री वाले उत्पाद दिखने चाहिए? वे यहाँ नहीं दिखते। यदि आवश्यक हो, तो एग्रीगेट को एक पूर्ण श्रेणी-उत्पाद सेट में लेफ्ट जॉइन करें और परिभाषित करें कि क्या शून्य शीर्ष तीन स्तरों में भाग लेता है।
- क्या आउटपुट क्रम निर्धारक होना चाहिए? केवल राजस्व के आधार पर रैंक करें; रैंकिंग विंडो में
product_idजोड़ने से टाई नष्ट हो जाती है।ORDER BY category_id, revenue_rank, product_idके साथ प्रस्तुति को अलग से स्थिर करें।
30-सेकंड का उत्तर ढांचा
“मैं पूरी हो चुकी UTC Q2 ऑर्डरों को प्रति कैटेगरी और उत्पाद एक पंक्ति में एग्रीगेट करूँगा, फिर कैटेगरी और घटते राजस्व के अनुसार DENSE_RANK का उपयोग करूँगा क्योंकि आवश्यकता टाई के साथ तीन अलग-अलग स्तरों की है। एक CTE रैंक की गणना करती है, बाहरी क्वेरी revenue_rank <= 3 को फ़िल्टर करती है, और अंतिम ऑर्डरिंग केवल प्रदर्शन को स्थिर करती है। मैं टाई, तिमाही सीमाओं, रद्द किए गए ऑर्डरों और तीन से कम स्तरों वाली श्रेणियों का परीक्षण करूँगा।”
एक पूर्ण उत्तर में यह भी बताया जाना चाहिए कि एग्रीगेशन रैंकिंग से पहले क्यों होता है, तीन रैंकिंग फ़ंक्शन कैसे भिन्न होते हैं, और बड़े पैमाने पर रिपोर्टिंग अनुबंध और निष्पादन योजना दोनों को कैसे मान्य किया जाए।
चरण-दर-चरण गहन उत्तर
चरण 1: व्यावसायिक प्रश्न को ग्रेन और इनवेरिएंट्स के रूप में व्यक्त करें
परिणाम कुंजी order_id नहीं है; यह (category_id, product_id) है। प्रत्येक कुंजी को एग्रीगेट चरण में एक बार दिखाई देना चाहिए, और revenue उस कुंजी के लिए सभी पात्र लाइन-आइटम राशियों के योग के बराबर होना चाहिए। रैंकिंग ग्रेन को बदले बिना एक श्रेणी-स्थानीय स्तर जोड़ती है।
सिंटैक्स लिखने से पहले तीन इनवेरिएंट्स बताएं: प्रत्येक पात्र लाइन आइटम ठीक एक बार योगदान देता है; विभिन्न ऑर्डरों में समान उत्पाद को संयोजित किया जाता है; और एक श्रेणी का revenue_rank केवल उस श्रेणी के भीतर के राजस्व पर निर्भर करता है। ये इनवेरिएंट्स डुप्लिकेट जॉइन्स, लाइन-आइटम रैंकिंग और ग्लोबल रैंकिंग को तुरंत उजागर करते हैं।
चरण 2: उत्पाद ग्रेन में एग्रीगेट करने से पहले फैक्ट्स को फ़िल्टर करें
शुरुआत के लिए >= और अगली तिमाही की शुरुआत के लिए < का उपयोग करें। BETWEEN या 2026-06-30 23:59:59 के विपरीत, एक हाफ-ओपन इंटरवल उच्च टाइमस्टैम्प सटीकता को नहीं छोड़ता है और अगली तिमाही के साथ सुचारू रूप से जुड़ता है। timestamptz लिटरल्स पर स्पष्ट +00 अनुबंध को डेटाबेस सत्र समय क्षेत्र से स्वतंत्र रखता है।
जॉइन करने के बाद, स्टेटस और समय को फ़िल्टर करें, फिर category_id, product_id द्वारा समूहीकृत करें। इस PostgreSQL मॉडल में, quantity * unit_price एक सटीक संख्यात्मक अभिव्यक्ति बनी रहती है, और SUM सटीक मौद्रिक अंकगणित को बनाए रखता है। सुविधा के लिए इसे फ्लोटिंग पॉइंट में कास्ट न करें। एक प्रोडक्शन राजस्व रिपोर्ट के लिए मुद्रा और रिफंड सिमेंटिक्स की भी आवश्यकता होती है, लेकिन प्रदान किए गए कॉलम उन्हें तैयार नहीं कर सकते।
चरण 3: टाई अनुबंध से रैंकिंग फ़ंक्शन चुनें
मान लीजिए कि एक श्रेणी में उत्पाद राजस्व 100, 100, 90, 80 है:
ROW_NUMBERसे1, 2, 3, 4प्राप्त होता है। अतिरिक्त कुंजी के बिना, दो 100 पंक्तियों का सापेक्ष क्रम अनिर्दिष्ट होता है। यह उदाहरण दोनों 100 पंक्तियों और एक 90 पंक्ति को लौटाता है, लेकिन तीसरी-पंक्ति की सीमा को पार करने वाली टाई को मनमाने ढंग से काट दिया जाएगा। यह तीन पंक्तियों की गारंटी देता है, पूर्ण टाई की नहीं।RANKसे1, 1, 3, 4प्राप्त होता है। 3 पर फ़िल्टर करने से राजस्व 100 और 90 प्राप्त होता है, केवल दो अलग-अलग स्तर।DENSE_RANKसे1, 1, 2, 3प्राप्त होता है। 3 पर फ़िल्टर करने से सभी चार उत्पाद और ठीक तीन अलग-अलग स्तर प्राप्त होते हैं।
इसलिए इस प्रॉम्प्ट के लिए DENSE_RANK की आवश्यकता है। इसकी विंडो ORDER BY में केवल revenue DESC होना चाहिए। product_id जोड़ने का अर्थ है कि समान-राजस्व वाली पंक्तियां अब सहकर्मी (peers) नहीं हैं, जो चुपचाप "टाई को सुरक्षित रखें" को एक निर्मित क्रम से बदल देती हैं।
चरण 4: दो CTE के साथ एग्रीगेशन, रैंकिंग और फ़िल्टरिंग को अलग करें
पूर्ण PostgreSQL क्वेरी है:
WITH product_revenue AS ( SELECT oi.category_id, oi.product_id, SUM(oi.quantity * oi.unit_price) AS revenue FROM orders AS o JOIN order_items AS oi ON oi.orderid = o.orderid WHERE o.status = 'COMPLETED' AND o.ordered_at >= TIMESTAMPTZ '2026-04-01 00:00:00+00' AND o.ordered_at < TIMESTAMPTZ '2026-07-01 00:00:00+00' GROUP BY oi.categoryid, oi.productid ), ranked AS ( SELECT category_id, product_id, revenue, DENSE_RANK() OVER ( PARTITION BY category_id ORDER BY revenue DESC ) AS revenue_rank FROM product_revenue ) SELECT categoryid, productid, revenue, revenue_rank FROM ranked WHERE revenue_rank <= 3 ORDER BY categoryid, revenuerank, product_id;
पहला चरण कई ऑर्डर आइटम्स को उत्पाद फैक्ट्स में कम करता है। दूसरा केवल प्रत्येक श्रेणी के भीतर उत्पाद सेट को सॉर्ट करता है। बाहरी क्वेरी तब विंडो परिणाम को देख और फ़िल्टर कर सकती है। ये चरण मीट्रिक अनुबंध, रैंकिंग अनुबंध और आउटपुट अनुबंध को प्रतिबिंबित करते हैं, इसलिए उनके ग्रेन और पंक्ति गणनाओं का स्वतंत्र रूप से निरीक्षण किया जा सकता है।
चरण 5: केवल सिंटैक्स दिखाने के बजाय सटीकता सिद्ध करें
किसी भी श्रेणी के लिए, पहला चरण प्रति उत्पाद एक कुल राशि बनाता है। PARTITION BY category_id तुलना से हर दूसरी श्रेणी को बाहर करता है, और ORDER BY revenue DESC समान योगों को एक पीयर समूह के रूप में परिभाषित करता है। DENSE_RANK बिना अंतराल के लगातार पीयर समूहों को संख्या देता है, इसलिए <= 3 ठीक तीन उच्चतम विशिष्ट योगों और उनसे संबंधित प्रत्येक उत्पाद का चयन करता है।
अंतिम ORDER BY रैंक को प्रभावित नहीं करता है; यह केवल लौटाई गई पंक्तियों को क्रमबद्ध करता है। यह अंतर मायने रखता है: विंडो के भीतर ऑर्डरिंग व्यावसायिक रैंक को परिभाषित करती है, जबकि अंत में ऑर्डरिंग दोहराने योग्य प्रस्तुति को परिभाषित करती है। वे विभिन्न कुंजियों का उपयोग कर सकते हैं।
चरण 6: प्रदर्शन के दावों को साक्ष्यों से जोड़कर रखें
यदि R पात्र लाइन आइटम G श्रेणी-उत्पाद समूह बन जाते हैं, तो तार्किक कार्य R पंक्तियों को स्कैन और एग्रीगेट करता है, फिर श्रेणियों के भीतर G पंक्तियों को सॉर्ट करता है। सॉर्टिंग को श्रेणी विभाजनों में G_c log G_c के योग के रूप में वर्णित किया जा सकता है, लेकिन PostgreSQL हैश एग्रीगेशन, सॉर्ट एग्रीगेशन, समानांतर निष्पादन, या डिस्क स्पिल चुन सकता है। वह अभिव्यक्ति भौतिक योजना के बारे में कोई वादा नहीं है।
फ़िल्टर की गई पंक्तियों, जॉइन रणनीति, एग्रीगेट पंक्तियों, सॉर्ट मेमोरी और अस्थायी फ़ाइलों का निरीक्षण करने के लिए प्रोडक्शन-स्केल प्रतिकृति पर EXPLAIN (ANALYZE, BUFFERS) का उपयोग करें। स्थिति की चयनात्मकता (selectivity), वितरण और विभाजन के आधार पर orders(status, ordered_at, order_id) और order_items(order_id) फ़िल्टरिंग और जॉइनिंग में मदद कर सकते हैं। समय विभाजन एक बड़ी फैक्ट तालिका को प्रून कर सकता है। बार-बार आने वाली रिपोर्ट के लिए, एक सुलझाए गए दैनिक श्रेणी-उत्पाद एग्रीगेट पर विचार करें। प्री-एग्रीगेशन क्वेरी गति के लिए ताजगी, बैकफ़िल और सुधार जटिलता का व्यापार करता है; "एक मटीरियलाइज्ड व्यू बनाएं" एक संपूर्ण डिज़ाइन नहीं है।
चरण 7: छोटे डेटा के साथ सिमेंटिक्स और बड़े डेटा के साथ लागत सिद्ध करें
एक न्यूनतम सटीकता फिक्सचर में राजस्व 100, 100, 90, 80, 70 के साथ श्रेणी 10 शामिल है; रैंक 1, 1, 2, 3 वाले पहले चार उत्पादों की अपेक्षा करें। श्रेणी 20 में केवल 50, 40 है; दोनों की अपेक्षा करें। एक रद्द किया गया ऑर्डर शामिल करें, जिसका योगदान नहीं होना चाहिए, और ठीक 2026-07-01 00:00:00+00 पर एक ऑर्डर, जिसे बाहर रखा जाना चाहिए।
यह सुनिश्चित करने के लिए कि यह एक कुल उत्पादन करता है, एक ही उत्पाद के लिए कई ऑर्डर और लाइन आइटम जोड़ें। एक स्थिर अंतिम क्रम लेकिन समान रैंक सत्यापित करने के लिए विभिन्न उत्पाद आईडी को समान कुल दें। स्केल वैलिडेशन फिर स्कैन किए गए विभाजनों, एग्रीगेट कार्डिनैलिटी, सॉर्ट स्पिल, बीता हुआ समय और शीर्ष संसाधनों की जांच करता है। सही आउटपुट और स्वीकार्य लागत साक्ष्य के अलग-अलग हिस्से हैं।
उच्च गुणवत्ता वाला नमूना उत्तर
“मैं पहले टाई व्यवहार, समय एट्रिब्यूशन और पात्र स्थिति को स्पष्ट करूँगा। आवश्यकता प्रति श्रेणी तीन उच्चतम अलग-अलग राजस्व स्तरों की है जिसमें प्रत्येक तीसरे स्तर का टाई शामिल है, इसलिए मैं DENSE_RANK का उपयोग करूँगा; मैं केवल ठीक तीन पंक्तियों के लिए ROW_NUMBER का उपयोग करूँगा।
लक्षित ग्रेन प्रति श्रेणी और उत्पाद एक पंक्ति है, जबकि स्रोत ग्रेन एक ऑर्डर आइटम है। इसलिए मेरी पहली CTE ऑर्डरों को आइटम्स से जोड़ती है, UTC Q2 में COMPLETED ऑर्डरों को रखती है, और category_id, product_id द्वारा SUM(quantity * unit_price) को एग्रीगेट करती है। मैं 1 अप्रैल समावेशी और 1 जुलाई अनन्य का उपयोग करता हूँ ताकि आसन्न तिमाहियाँ ओवरलैप न हों।
दूसरी CTE DENSE_RANK() OVER (PARTITION BY category_id ORDER BY revenue DESC) लागू करती है। मैं उस विंडो में product_id नहीं जोड़ता क्योंकि यह समान-राजस्व वाले साथियों को विभाजित कर देगा। PostgreSQL उसी क्वेरी स्तर के WHERE में विंडो परिणाम को फ़िल्टर नहीं कर सकता है, इसलिए बाहरी क्वेरी revenue_rank <= 3 लागू करती है और फिर स्थिर प्रदर्शन के लिए श्रेणी, रैंक और उत्पाद आईडी द्वारा क्रमबद्ध करती है।
राजस्व 100, 100, 90, 80 रैंक 1, 1, 2, 3 बन जाते हैं, इसलिए सभी चार उत्पाद वापस आते हैं। मैं रद्द किए गए ऑर्डरों, तिमाही की सही सीमा, एक उत्पाद के लिए दोहराए गए लाइन आइटम्स और तीन से कम स्तरों वाली श्रेणियों का भी परीक्षण करूँगा। बड़े पैमाने पर, मैं विभाजन प्रूनिंग, इंडेक्स, स्पिल ट्यूनिंग, या प्री-एग्रीगेशन को सही ठहराने के लिए निष्पादन योजना का उपयोग करने से पहले यह मापूँगा कि फ़िल्टरिंग और एग्रीगेशन R स्रोत पंक्तियों को कितना कम करते हैं।”
यह उत्तर सिंटैक्स से पहले व्यावसायिक सिमेंटिक्स स्थापित करता है, फिर क्वेरी संरचना, सटीकता साक्ष्य और एक मापा प्रदर्शन पथ प्रदान करता है। यह किसी फ़ंक्शन नाम या किसी अप्रयुक्त इंडेक्स सुझाव को उत्तर नहीं मानता है।
सामान्य गलतियाँ
- ऑर्डर आइटम्स को सीधे रैंक करना → एक उत्पाद कई स्थानों पर कब्जा कर लेता है और आउटपुट ग्रेन गलत होता है → रैंकिंग से पहले श्रेणी और उत्पाद द्वारा एग्रीगेट करें।
- ग्लोबल
ORDER BY ... LIMIT 3का उपयोग करना → यह संपूर्ण डेटा सेट के लिए तीन पंक्तियाँ लौटाता है →category_idद्वारा रैंकिंग को विभाजित करें। - बिना टाई अनुबंध के
ROW_NUMBERचुनना → टाई हुए उत्पादों को मनमाने ढंग से काटा जा सकता है → पहले तीन पंक्तियों, कॉम्पिटिशन पोजीशन, या तीन अलग-अलग मानों को परिभाषित करें। DENSE_RANKऑर्डरिंग मेंproduct_idजोड़ना → समान राजस्व वाले साथी नहीं रह जाते हैं → केवल व्यावसायिक रैंक कुंजियों पर रैंक करें और अंतिमORDER BYमें प्रदर्शन को स्थिर करें।- उसी
WHEREमेंrevenue_rankको फ़िल्टर करना → विंडो परिणाम उस तार्किक चरण में मौजूद नहीं होता है → एक CTE या सबक्वेरी में रैंक करें और बाहर फ़िल्टर करें। - तिमाही को June 30 23:59:59 पर समाप्त करना → उच्च टाइमस्टैम्प सटीकता छूट सकती है और आसन्न अवधियाँ अजीब होती हैं →
[start, next_start)का उपयोग करें। - ऐतिहासिक सिमेंटिक्स के बिना आज के श्रेणी डायमेंशन को जॉइन करना → उत्पाद पुनर्वर्गीकरण इतिहास को फिर से लिखता है → एक ऑर्डर-टाइम स्नैपशॉट या प्रभावी-दिनांकित डायमेंशन का उपयोग करें और अनुबंध बताएं।
- केवल एक इंडेक्स की पेशकश करना → कम चयनात्मकता इसे बेकार बना सकती है, और यह गलत ग्रेन को ठीक नहीं कर सकती है → कार्डिनैलिटी, योजना, स्पिल और वास्तविक बाधा को मापें।
- फ्लोटिंग पॉइंट में धन का संचय करना → राउंडिंग टाई समूहों को बदल सकती है → एक सटीक संख्यात्मक प्रकार बनाए रखें और मुद्रा और शुद्ध-राजस्व नियमों को परिभाषित करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: क्या होगा यदि उत्पाद को प्रति श्रेणी ठीक तीन पंक्तियों की आवश्यकता हो?
ROW_NUMBER का उपयोग करें और समान राजस्व के लिए एक व्याख्या योग्य निर्धारक माध्यमिक क्रम परिभाषित करें, जैसे कि product_id ASC या स्पष्ट रूप से अनुरोधित बेची गई इकाइयाँ या लॉन्च-तिथि नियम। वह नियम जानबूझकर टाई को तोड़ता है, इसलिए यह आउटपुट अनुबंध से संबंधित है। तीन से कम उत्पादों वाली श्रेणी अभी भी कम पंक्तियाँ लौटाती है जब तक कि प्लेसहोल्डर्स की स्पष्ट रूप से आवश्यकता न हो।
फॉलो-अप 2: क्या होगा यदि “शीर्ष तीन” कॉम्पिटिशन रैंकिंग का उपयोग करता है?
RANK का उपयोग करें। राजस्व 100, 100, 90, 80 को 1, 1, 3, 4 प्राप्त होता है, और 3 पर फ़िल्टर करने पर 100 और 90 स्तर वापस आते हैं। यह एक टाई के बाद अंतर को बनाए रखता है, जो "अगला उत्पाद तीसरा है" से मेल खाता है। यह DENSE_RANK के साथ शीर्ष तीन विशिष्ट मानों का अनुरोध करने से भिन्न है।
फॉलो-अप 3: क्या आप CTE से बच सकते हैं और HAVING में रैंक को फ़िल्टर कर सकते हैं?
आप उसी क्वेरी स्तर के HAVING या WHERE में विंडो परिणाम को फ़िल्टर नहीं कर सकते हैं, क्योंकि विंडो फ़ंक्शंस तार्किक रूप से बाद में होते हैं। एक समकक्ष सबक्वेरी काम करती है। कुछ डेटा वेयरहाउस QUALIFY का समर्थन करते हैं, लेकिन PostgreSQL 18 नहीं करता है। यहाँ CTE एग्रीगेशन, रैंकिंग और फ़िल्टरिंग सीमाओं को स्पष्ट बनाता है।
फॉलो-अप 4: क्या होगा यदि अगली तिमाही में कोई रिफंड होता है?
पहले लेखांकन अनुबंध को परिभाषित करें। एक ऑर्डर-एट्रिब्यूशन रिपोर्ट मूल ऑर्डर तिमाही को दोहरा सकती है; एक कैश-फ्लो रिपोर्ट रिफंड तिमाही में एक नकारात्मक घटना दर्ज कर सकती है। उनके लिए अलग-अलग घटना समय और फैक्ट तालिकाओं की आवश्यकता होती है। ऐसी रिफंड तालिका को न घटाएं जिसमें राशि और घटना-समय सिमेंटिक्स की कमी हो; ट्रेस करने योग्य ऑर्डर और रिफंड फैक्ट्स को मॉडल करें और रीस्टेटमेंट या समायोजन नीति बताएं।
फॉलो-अप 5: आप एक अरब त्रैमासिक लाइन आइटम्स को कैसे संभालेंगे?
रैंकिंग से पहले दिनांक विभाजनों को प्रून करें और स्थिति को फ़िल्टर करें, फिर जॉइन-कुंजी इंडेक्स, एग्रीगेट पैरेललिज्म और सॉर्ट स्पिल का निरीक्षण करें। यदि रिपोर्ट बार-बार आती है और देरी सहन कर सकती है, तो एक सटीक दैनिक श्रेणी-उत्पाद एग्रीगेट बनाए रखें और तिमाही के लिए इसका योग करें। देर से आने वाले ऑर्डरों, रिफंडों और सुधारों के लिए इडेम्पोटेंट बैकफ़िल और रॉ फैक्ट्स के साथ समाधान की आवश्यकता होती है। केवल निष्पादन योजना और एक प्रतिनिधि वर्कलोड ही इंडेक्सिंग, पार्टिशनिंग और प्री-एग्रीगेशन के बीच चयन कर सकते हैं।
फॉलो-अप 6: आप ऐसे जॉइन का पता कैसे लगाते हैं जिसने राजस्व को दोगुना कर दिया?
प्रत्येक चरण में ग्रेन और संरक्षण की जाँच करें: क्या पात्र-आइटम जॉइन में पंक्ति गणना अपेक्षित कार्डिनैलिटी से मेल खाती है, क्या orders.order_id अद्वितीय है, और क्या उत्पाद एग्रीगेट्स का योग फ़िल्टर किए गए आइटम राशियों के योग के बराबर है। एक ऑर्डर में दो आइटम्स और एक डुप्लिकेट डायमेंशन की के साथ एक काउंटर-उदाहरण जोड़ें। यदि कोई डायमेंशन अद्वितीय नहीं है, तो जॉइन करने से पहले एक प्रभावी-दिनांकित संस्करण चुनें; एक अंतिम DISTINCT केवल डुप्लिकेट योगदान को छुपाता है।