Forum Discussion
miked
2 years agoContributor
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...
- 2 years ago
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.
- 2 years ago
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.
RobbSalzmann
2 years agoValued Contributor II
How many cubes are you thinking? I think we all would agree that after a while too much of anything can adversely impact maintainability, performance, or useability. Which two of these is important to your client?
In aviation we have an expression: "With enough thrust, anything will fly". 🙂
miked
2 years agoContributor
The idea we were exploring was a seperate cube for each entity for which there are 120 now...but that would grow by 10 or so a year. I totally agree on the concerns. We're still scoping it out but yes, all 3 of those factors are important and come into play.
My sense is 100+ cubes seems over the top and the lookup table option might be more sensible. Only drawback to lookup / XFBR's is the user would need to know how to use them when creating a custom quickview on the fly.
Related Content
- 2 years ago
- 9 months ago
- 14 days ago