I have been trying out a few index views and am impressed but I nearly always need a max or a min as well and can not understand why it doesn't work with these, can anyone explain why?
I KNOW they are not allowed, I just can't understand why!!! Count etc. is allowed why not MIN/MAX, I'm looking for explanation...
These aggregates are not allowed because they cannot be recomputed solely based on the changed values.
Some aggregates, like
COUNT_BIG()
orSUM()
, can be recomputed just by looking at the data that changed. These are allowed within an indexed view because, if an underlying value changes, the impact of that change can be directly calculated.Other aggregates, like
MIN()
andMAX()
, cannot be recomputed just by looking at the data that is being changed. If you delete the value that is currently the max or min, then the new max or min has to be searched for and found in the entire table.The same principle applies to other aggregates, like
AVG()
or the standard variation aggregates. SQL cannot recompute them just from the values changed, but needs to re-scan the entire table to get the new value.Besides the reasons specified by Remus, there is less practical need to support MIN and MAX. Unlike COUNT() or SUM(), MAX and MIN are fast to calculate - you are all set after just one lookup; you don't need to read a lot of data.
Aggregate functions like MIN/MAX aren't supported in indexed views. You have to do the MIN/MAX in the query surrounding the view.
There's a full definition on what is and isn't allowed within an indexed view here (SQL 2005).
Quote: