<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Dynamic and Conditional grouping in SQL queries &#8211; for flexible results from single query (oh and a useful case for the CUBE operator)</title>
	<atom:link href="http://technology.amis.nl/2008/11/22/dynamic-and-conditional-grouping-in-sql-queries-for-flexible-results-from-single-query-oh-and-a-useful-case-for-the-cube-operator/feed/" rel="self" type="application/rss+xml" />
	<link>http://technology.amis.nl/2008/11/22/dynamic-and-conditional-grouping-in-sql-queries-for-flexible-results-from-single-query-oh-and-a-useful-case-for-the-cube-operator/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=dynamic-and-conditional-grouping-in-sql-queries-for-flexible-results-from-single-query-oh-and-a-useful-case-for-the-cube-operator</link>
	<description></description>
	<lastBuildDate>Fri, 12 Apr 2013 10:04:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Rob van Wijk</title>
		<link>http://technology.amis.nl/2008/11/22/dynamic-and-conditional-grouping-in-sql-queries-for-flexible-results-from-single-query-oh-and-a-useful-case-for-the-cube-operator/#comment-5583</link>
		<dc:creator>Rob van Wijk</dc:creator>
		<pubDate>Mon, 24 Nov 2008 20:04:52 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=4162#comment-5583</guid>
		<description><![CDATA[Hi Lucas,

You can use CUBE as an inefficient row generator (&quot;select rownum from (select 1 from dual group by cube(1,1,1,1)) where rownum &lt;= 13&quot;) or maybe for some obscure BI query or report. I&#039;ll have to ask this to some BI colleagues. However, you said it perfectly: &quot;CUBE will aggregate along all dimensions and at all levels - while we will always need just a subset&quot;. I think CUBE has become almost obsolete for normal development, since the advent of grouping sets. With grouping sets you can specify exactly which grouping you want, without having to calculate everything first and then filter.

Regards,
Rob.]]></description>
		<content:encoded><![CDATA[<p>Hi Lucas,</p>
<p>You can use CUBE as an inefficient row generator (&#8220;select rownum from (select 1 from dual group by cube(1,1,1,1)) where rownum &lt;= 13&#8243;) or maybe for some obscure BI query or report. I&#8217;ll have to ask this to some BI colleagues. However, you said it perfectly: &#8220;CUBE will aggregate along all dimensions and at all levels &#8211; while we will always need just a subset&#8221;. I think CUBE has become almost obsolete for normal development, since the advent of grouping sets. With grouping sets you can specify exactly which grouping you want, without having to calculate everything first and then filter.</p>
<p>Regards,<br />
Rob.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lucas Jellema</title>
		<link>http://technology.amis.nl/2008/11/22/dynamic-and-conditional-grouping-in-sql-queries-for-flexible-results-from-single-query-oh-and-a-useful-case-for-the-cube-operator/#comment-5582</link>
		<dc:creator>Lucas Jellema</dc:creator>
		<pubDate>Mon, 24 Nov 2008 05:02:31 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=4162#comment-5582</guid>
		<description><![CDATA[Hi Rob, &lt;br /&gt;Thanks for your response. Yes, you are right on both accounts. I did not use the HAVING because of the way in which I expect the application to make use of this query. Manipulating the where-clause is much easier in the application than fiddling with the HAVING clause, that&#039;s why I approached it like this. And of course the CUBE will aggregate along all dimensions and at all levels - while we will always need just a subset. How costly that proves to be? The percentage unnecessary aggregations can grow quite large, depending on the logic in the application - up to 95% or more. So perhaps this is not a very good example of CUBE usage after all. Do you know one?&lt;br /&gt;regards, Lucas]]></description>
		<content:encoded><![CDATA[<p>Hi Rob, <br />Thanks for your response. Yes, you are right on both accounts. I did not use the HAVING because of the way in which I expect the application to make use of this query. Manipulating the where-clause is much easier in the application than fiddling with the HAVING clause, that&#8217;s why I approached it like this. And of course the CUBE will aggregate along all dimensions and at all levels &#8211; while we will always need just a subset. How costly that proves to be? The percentage unnecessary aggregations can grow quite large, depending on the logic in the application &#8211; up to 95% or more. So perhaps this is not a very good example of CUBE usage after all. Do you know one?<br />regards, Lucas</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob van Wijk</title>
		<link>http://technology.amis.nl/2008/11/22/dynamic-and-conditional-grouping-in-sql-queries-for-flexible-results-from-single-query-oh-and-a-useful-case-for-the-cube-operator/#comment-5581</link>
		<dc:creator>Rob van Wijk</dc:creator>
		<pubDate>Sat, 22 Nov 2008 13:20:40 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/?p=4162#comment-5581</guid>
		<description><![CDATA[Lucas,

Nice post.
Two remarks though:
 1) the CUBE query will look much easier when using the HAVING clause, since there won&#039;t be a need for the inline view in that case.
 2) the CUBE query will be less performant than your first query as it has to calculate all grouping sets first before being able to filter on them. To verify: in the explain plan you&#039;ll see a &quot;GENERATE CUBE&quot; step with a much larger number in the A-rows column than the number of rows in your table.

Regards,
Rob.]]></description>
		<content:encoded><![CDATA[<p>Lucas,</p>
<p>Nice post.<br />
Two remarks though:<br />
 1) the CUBE query will look much easier when using the HAVING clause, since there won&#8217;t be a need for the inline view in that case.<br />
 2) the CUBE query will be less performant than your first query as it has to calculate all grouping sets first before being able to filter on them. To verify: in the explain plan you&#8217;ll see a &#8220;GENERATE CUBE&#8221; step with a much larger number in the A-rows column than the number of rows in your table.</p>
<p>Regards,<br />
Rob.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
