Rationale behind NOT mixing S & N elements in measure dim?

[harrytm1]

When I started using TM1, I was told not to create a cube with a mix of S and N elements in the measure dimension.

I recently created a cube with mixed elements just to test this guiding principle. I also wrote rules that use the string data in the cube and feed both strings and numeric data into another cube.

Performance seems to be fine, albeit the cube has only two sets of data and has 5 dimensions.

Can a guru in this forum enlighten me on the rationale of not mixing? many thanks.

[lotsaram]

For small cubes with limited dimensionality such as system lookups there's no real harm in mixing N and S measures however in general it is best to stick with N only measures in a cube of any significant size. The reason being that it is the last dimension of a cube that defines string measures and once string values are held in a cube this vastly limits the ability to optimize dimension order (and therefore cube memory and query performance) as the last dimension is by far the most significant in terms of optimal dimension order.

Usually as strings would form a relatively small part of the overall data set (comments etc.) it is much better practice to create a separate cube for the string values, this means that database size and query performance can be properly optimized.

[Steve Rowe]

I'd guess that this rule of thumb came about before feed strings too. Like lotsaRam says it's more ofa design thing since usually the dimensionality of string data is often very data to the numeric data it is associated with.
What ever works, works!
Cheers

[Alan Kirk]

In addition to the reasons that Lotsaram and Steve gave, one trap for new players is... strings don't consolidate. You can enter them at consolidation level, but if you enter some descriptive text at (say) individual department level and expect to see anything at Total Department level (without re-entering it at that level), you'll be very disappointed. On the other hand if you have a numeric values cube and a string cube, doing a lookup of the corresponding string via Excel formulas in a report is relatively easy. Certainly a lot easier than creating rules to handle every possible way the cube could be viewed via an ad hoc query, or populating every possible combination.