Question

I have a set of approx 1 million rows (approx rowsize: 1.5kb) that needs to be “cached” so that many different parts of our application can utilize it.

These rows are a derived/denormalized “view” of compiled data from other tables. Generating this data isn’t terribly expensive (30-60sec) but is far too slow to generate “on the fly” as part of a view or table-valued function that the application can query directly. I want to update this data periodically, perhaps every few minutes.

My first thought is to have a scheduled job that updates a global temp table with this data every n minutes.

What’s the best strategy, performance-wise? I’m not sure of the performance implications of storing it in a real table versus a global temp table (##tablename) versus other strategies I haven’t thought of. I don’t want to muck up the transaction logs with inserts to this table… it’s all derived data and doesn’t need to be persisted.

I’m using Microsoft SQL Server 2000. Upgrading during the timeframe of this project isn’t an option, but if there’s functionality in 2005/2008/2010 that would make this easier, I’d appreciate hearing about that.

Answer 1

I’d recommend using a materialized view (AKA indexed view).

Limitations:

1. View definition must always return the same results from the same underlying data.
2. Views cannot use non-deterministic functions.
3. The first index on a View must be a clustered, UNIQUE index.
4. If you use Group By, you must include the new COUNT_BIG(*) in the select list.

5. View definition cannot contain the following:

   1. TOP
   2. Text, ntext or image columns
   3. DISTINCT
   4. MIN, MAX, COUNT, STDEV, VARIANCE, AVG
   5. SUM on a nullable expression
   6. A derived table
   7. Rowset function
   8. Another view
   9. UNION
   10. Subqueries, outer joins, self joins
   11. Full-text predicates like CONTAIN or FREETEXT
   12. COMPUTE or COMPUTE BY
   13. Cannot include order by in view definition