mike,

i didn’t think that you were rude, but i could sense your frustration. and you are correct, a cube is not needed in every case, but a change will need to be made somewhere.

I guess it’s not the level of detail in the cube but the type of reports coming back from the cube. A lot of transactional listing type data. It’s not aggregates or summaries of that atomic data but transactional high row count reports.

After re-reading my comment, I see that I sounded rude in my response. You have never lied to me Batman. Don’t take my bat signal away. I guess I was frustrated with the cubes I am supporting, not you.

I agree having a separate database (or cube) for reporting does make a lot of sense as you explain it. Just saying that cubes are not the answer for every type of reporting.

I think we need to get Mr. Myers to come up here and work through our architecture when the powers that be allow it.

As far as I’m aware, you should actually be building your cubes down to the most atomic level possible. Kimball’s Data Warehouse Toolkit gets into a lot of the details of building and designing cubes. There’s some great stuff in there.

Have I ever lied to you before, as far as you know?

Cubes can be very detailed as well, they just need to be built to the right specifications. The point here is that if you have performance issues related to one group of users entering data and another group trying to report on that data, you may want to think about a different architecture. In most cases people tend to just think about a seperate database for reporting. But you may want to consider a cube as well.

I recently have been working on the opposite problem with poorly designed cubes handling a lot of relational reporting duties.

Agree that cubes are quite useful though and they can often answer a lot of great reporting questions.