TM1 Forum

Hi all,
i happened to read in one of bedrocktm1's white papers that it was bad practise to do this because of the effect on performance - however, because im feeling particularly lazy and dont feel like creating a whole separate cube for commentary on financials, I was considering combining numbers + comments in the same cube... :p

So just wondering from people's experience how bad the effect on performance actually is to do this...?

There is no real impact these days with FeedStrings available. The only rule you have to remember is that string elements still have to be in the last dimension of the cube,

Jim.

I've never had a problem mixing the two. Though I rarely have had enormous cubes that also have text data. Like any decision about whether to split cubes or not it's a matter of balancing performance, usability and manageability.

Martin

fleaster wrote:Hi all,
i happened to read in one of bedrocktm1's white papers that it was bad practise to do this because of the effect on performance - however, because im feeling particularly lazy and dont feel like creating a whole separate cube for commentary on financials, I was considering combining numbers + comments in the same cube... :p

So just wondering from people's experience how bad the effect on performance actually is to do this...?

How bad the performance impact? It all depends
- what is the size and density of the last dimension that contains the N and S elements?
- what is the difference in size and density between the last dimension (fixed in position by virtue of string data) vs the dimension that would otherwise be optimally last?
- how big is the cube?
- how sparse is the cube?
- what is the complexity of rules?
- are the strings data only or a mixture of data entry and rules?

The reason it's a sub-optimal (depending on circumstance) to mix N and S data types is that once string data is stored it is then no longer possible to optimize the cube as the last dimension is fixed in position. Although you can in theory still "optimize" the order of the remaining dimensions there's not really much point in doing so due to diminishing returns as about 90% of the possible optimization benefit is from the correct last dimension, 9% from the 2nd last, 0.9% from the 3rd last ... and then who cares (actually who cares after the 1st dimension). That's why it's a "bad" practice.

Certainly for any large cube that needs to be optimized for reporting it's not a good practice to mix in string elements. But for smaller cubes or cubes with only 2 or 3 dimensions it really makes no difference at all. And sometimes (like when building applications in Contributor) there may simply be no choice.

ok thanks for the tips... our financials cube is fairly large; and the new one we are currently building could have 12 to 18 dimensions... so am guessing the thing to do is feed the data to an identical cube w/ a commentary dimension in this case...

I am with lotsaram there.
And in your case with 12 - 18 dimensions in the cube I would definitely try without string elements.

fleaster wrote:12 to 18 dimensions

That is a LOT of dimensions. Are you really sure you need that many? Maybe I'm misunderstanding what you mean by "financials" (I take it to be the GL), but I'm having a hard time imagining the need for so many.

Matt

Well yes it's mo

mattgoff wrote:

fleaster wrote:12 to 18 dimensions

That is a LOT of dimensions. Are you really sure you need that many? Maybe I'm misunderstanding what you mean by "financials" (I take it to be the GL), but I'm having a hard time imagining the need for so many.

Matt

well yes it's really for General Ledger analysis/reporting... actually i didnt think 18 dimensions was alot for a cube...? maybe i'll put it up on another post