Forum Discussion
Solved
Cube Limit
Hi All,
I have a bit of an extreme question here. Is there any limit, whether system or logically, that there are too many cubes in an application? My example (which I have simplified here for il...
Given the relationship of cost centers to entities you describe, where any given cost center belongs to only one entity, I see cost centers naturally rolling up to entities and would keeps them all in the same dimension type.
With each cost center relating to only its entity, there most likely isn’t a reporting or data entry use case that would benefit from intersecting these using different dimension types.
I would roll them up to their entity based on the info here. I don’t think you give up much flexibility with single member sparsity by keeping things fairly simple.
To me, this sounds like you need a "Register", a custom table like you have in Marketplace solutions, keeping records for cost centers; then you can pump aggregated data in the cube, or even leave everything in that custom table (or in Stage, as an Attribute) and just blend data on reports. You could leverage BiBlend to do aggregations if you have complex hierarchies.
Data specific to one or two Entities makes for bad UDs. They're more like Attributes, or custom data.
This said, 3000 members in one UD might not be the end of the world, if the rest of your hierarchies is smallish and your rules are well-built.
Thx Rick. yes that is similar to what we think we will end up doing (summary, detail cube). However, I still think we want to avoid having the 3000 UD1 members even if we leverage constraints. Having that many members in a dimension just makes drilling in Excel slower especially if it's done in combination with another dimension with a couple hundred other members. But I agree with your thinking and am a strong proponent of constraints as well. Thx
If it helps, I have a client with this design/similar issue with sparsity and around 75k members in UD1 with no performance issues on drill downs in excel/app. The key is to make sure you have suppression on before drilling down on a quick view/cubeview.
By using the constraints, the "Suppress invalid" option will work nicely for suppressing out combinations automatically. Also make sure you look into sparse row suppression settings which can help cube view performance.
Thx Rick. That's impressive. We have seen performance issues in the past on some apps with the combination of a few dimensions having just a few hundred members when drilling on more than one at a time. Even with suppression turned on. We shall see on this one. Thx for the reply...much appreciated.