ध्यान दें कि आप वेतन की राशि प्राप्त करना चाहते हैं, ट्यूटोरियल डी में :
SUMMARIZE emp BY { job } ADD ( SUM ( sal ) AS total_sal )
नोट एकत्रीकरण एक रिलेशनल ऑपरेटर नहीं है, इसलिए यह रिलेशनल बीजगणित का हिस्सा नहीं बनेगा।
जहां तक HAVING का सवाल है , क्या यह एक ऐतिहासिक विसंगति है। SQL-92 मानक से पहले, SELECT . लिखना संभव नहीं था FROM . में भाव क्लॉज (a.k.a व्युत्पन्न टेबल) यानी आपको सभी काम एक SELECT में करने थे अभिव्यक्ति। SQL के कठोर मूल्यांकन आदेश के कारण, WHERE के बाद समग्र मान अस्तित्व में नहीं आता है खंड का मूल्यांकन किया गया है यानी समेकित मूल्यों के आधार पर प्रतिबंध लागू करना असंभव था। HAVING इस समस्या के समाधान के लिए पेश किया गया था।
लेकिन HAVING . के साथ भी , जब तक व्युत्पन्न तालिकाओं को पेश नहीं किया गया था, तब तक कोड के संबंध में SQL रिलेशनल रूप से अधूरा रहा। व्युत्पन्न तालिकाओं का प्रतिपादन किया गया HAVING बेमानी लेकिन HAVING . का उपयोग कर रहे हैं अभी भी लोकप्रिय है (यदि स्टैक ओवरफ्लो कुछ भी हो जाए):लोक अभी भी एक ही SELECT का उपयोग करना पसंद करते हैं जहां संभव हो और मूल्यांकन आदेश के संबंध में एसक्यूएल की पूर्वोक्त कठोरता (प्रक्षेपण एक SELECT में अंतिम रूप से किया जाता है अभिव्यक्ति) HAVING . की तुलना में व्युत्पन्न तालिका उपयोग को काफी क्रियात्मक बनाता है ।
