Forum Discussion

miked's avatar
miked
Contributor
10 months ago

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...
  • RobbSalzmann's avatar
    10 months 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. 

  • JackLacava's avatar
    10 months 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.