Big dimension performance

[Willi]

Hello,

I inherited a model where we have a Dimension of Articles. This Dimension has 85.000 Elements plus a couple of consolidated ones. And we have 110 Attributes. The handling of this Dimension is terribly slow. We read the attribuites with some processes, Frontends (with DBRW from }ElementAttributes_...) and in rules (with DBRA). Would it probably be better to transform this Dimension to an own cube?

We're looking for a starter-Point to discuss and test new Scenarios.

Thanks and regards,
Willi

[declanr]

This sort of thing is sadly normally a bit of a trial and error approach of seeing whether you get a benefit or not. Things to consider:

1/ If you have a lot of numeric attributes you will find that all attributes are (sort of) stored as strings... so you do tend to get better performance holding them in a real cube with a numeric measure instead.
2/ The big benefit is when you have that many elements there is a huge risk involved with turning on the view properties section of the subset editor, as it can end up reading all of the attributes in one go... whether you actually wanted to see them or not.
3/ It can sometimes be a bit less obvious what is going on for new developers taking over if you don't have the "attributes" held as attributes but instead in a cube.
4/ An alias obviously needs to be an attribute if you view data through a cube viewer BUT if your users tend to work through websheets then you can get smart on how you display the names if you have it in a separate cube.

My recommendation though would just be to give both a go and see what sort of performance benefits you get.

[jim wood]

I agree with Declan. Also have you considered breaking the dimension up? Create sub cubes and a summary cube using drill down between the cubes to replicate the current hierarchy? Based on what you've said I'm not sure if this wil fit but I thought it might be helpful to suggest it anyway,

Jim.

[Willi]

Thx declanr and Jim,

the alias is not an issue because the elements are not the naming elements for a cube- or Websheet-View.

If I read your Points Nr 1 from declanr seems a big benefit for us. Nr 3 is one you really are not allowed to Forget but this is a matter of documentation

Jim: your Point is not in question here. This Dimension is not used for consolidation. The Consolidated Elements are just the Article-Structure.

Thx I appreciate your suggestions

[declanr]

Jim: your Point is not in question here. This Dimension is not used for consolidation. The Consolidated Elements are just the Article-Structure.

If the consolidated elements have a lot of children but are not actually used for viewing you MAY find a slight benefit in getting rid of them and perhaps using subsets instead.

[Willi]

If the consolidated elements have a lot of children but are not actually used for viewing you MAY find a slight benefit in getting rid of them and perhaps using subsets instead.

Thx, I thought about this but we have a 3-Level Hirarchy. So this is difficult

[BariAbdul]

Jim: your Point is not in question here. This Dimension is not used for consolidation. The Consolidated Elements are just the Article-Structure.

If the consolidated elements have a lot of children but are not actually used for viewing you MAY find a slight benefit in getting rid of them and perhaps using subsets instead.

Now I know why my model has so many subset tinkering around the cubes,All I can say it doesn't look neat and tidy and finding the objects is really pain in the neck.Thanks