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.
KeithBerry
OneStream Employee
OneStream EmployeeWe have also used Rick's approach with success on a very large UD dimension. We first experimented with a 450-cube approach. It worked fine, but the two-cube approach Rick describes is easier to implement and maintain.
We use two other techniques to limit drill-through volume. We set Display Member Security linked to the entity on each UD member. Users only see the cost centers for the entities to which they have access. Also, on cube views and other reports we limit the cost center members using Where clauses, An example is U4#Root.Base.Where(Name Contains |CVEntity|). In our case the entity name was embedded in the cost center, but you could also place it on a text field. Both approaches limit our reliance on suppression, which seems to help performance.