Quoting [EMAIL PROTECTED]: > > Why would you want to do that? bananacount is something you can > > calculate with a LEFT JOIN and a GROUP BY, so storing it in the DB > > would break normalization. > > This would also the first step in creating your own OLAP cube. For each > statistic, you save yourself a lot of time if you compute the results of > several GROUP BY functions (SUM, AVG, STD, etc) and store those results > into intermediate tables. Then when you want to start slicing and dicing > your data, you do more retrieval and less computations. This seriously > improves the performance of your reports. Each new record inserted into > your cube would require you to update every computed statistics table that > covered your new record. But that *is* the trade off, isn't it? Much > faster analysis for much slower transaction performance. Thus the basic > difference between OLAP and OLTP.
This is closer to the reason why I'm trying to do this. Obviously this is an example: I'm not actually tracking real monkeys and real banannas with mysql. (Sorry if this disappoints anyone!) In my actual application I'm doing a JOIN between this table and another one with a GROUP BY (a very different criteria) and a HAVING clause which selects only members from this other table which have as many elements in this second grouping as appeared in the first grouping. So basically I'm trying to compare the results of two different GROUP BY statements with a HAVING clause and I'm pretty sure I can't do it all within one statement, so I'm caching the results of one of the GROUPs as a value in one of the tables. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
