After that, though, OLAP is just an optimization for [end users]. End users always ask for report versions: What region? What city? It doesnt mean you have to copy the data. The important thing were trying to do with OLAP is to present a business view of the data. Thats how business users think: "Show me the most profitable city for each product." Thats a really cool thing to be able to find out about a product line. Thats a conceptual view of the data. But we dont have to make a copy of the data warehouse and turn it into a cube view and stick it on the disk. We can look at it with a relational OLAP lens. Were not unique in that. But it does not require any duplication of the data. If you want, for performance reasons, we and other vendors can materialize a multidimensional view on disk. You get speed, you get faster queries. But we do not have to duplicate any data to do a report.No, Reporting Services does not require end users to cache any data. Im not sure where that perception came from. Optionally, we do caching, but we do it on the server. Whats the trade-off? Taking up space on the Reporting Services server. But youre saving the time and CPUs on the database server. Youre offloading the database server. You dont have to cache. You can cache when the first user comes in, keep the cache, expire the cache, keep it around three days or whatever. You have a lot of choices. Theres a lot of control and flexibility there. Whats the coolest feature of Report Builder? Templates. One principle is that its easier to edit than to create. If I give you a blank template, 99 percent of people just stare at it. If I give you common shapes and you can start from there, then youre off. Take it and modify it for your own needs. Next Page: The infinite coolness of infinite drilldown.
Does Reporting Services require users to cache data?