Attributes vs Lookup Cubes

[George Regateiro]

I inherited a model that was designed using a large amount of lookup cubes rather then attributes. I understand that in the end attributes turn into lookup cubes, but I was wondering if there has been any information as to which is faster. I did not know if there was any advantage to the attribute functions as opposed to get functions. I have been trying to get some improved performance since the model was designed on a 64 bit system without alot of concern for efficiency.

[David Usherwood]

I don't believe there is any difference since (as you say) attributes are held in a (string) cube anyway. My own approach is to have a cube if the lookup is multidimensional, and an attribute otherwise.

[Eric]

I believe the primary difference is that with attributes set up as an alias TI can recognize and load the alias as if it were a primary key.

[Martin Ryan]

I think it's merely "best practice" that suggests that if it's one dimensional then you use attributes, rather than performance. I personally think attributes are much cleaner as you can easily hide all that information away and yet easily access it as well, plus the alias functionality that Eric mentions.

I also don't know if there are any speed differences. I would doubt it.

Just, personal preference I think. In your case I wouldn't see a huge amount to be gained in investing a lot of time in changing over to attributes.

Cheers,
Martin

[George Regateiro]

Thanks for the replies. I will probably leave the current model alone since as Martin pointed out it was probably not worth the time to make the changes. I have already started down the attribute path for all my new models, but this one was hanging out there.

Thanks again.

[Steve Rowe]

The one big difference is the rules. In an attribute cube everything is basically a string and N: qualified rules don't compile. With a look up cube you have a lot more flexability
Cheers

[Steve Vincent]

depends on who needs the data too. in some cases where users have needed to open and close periods without wanting to meddle with rules or TIs, we've created control cubes that they can amend to do just that. attributes would have worked but getting to them is not as easy, especially if you have any desire to sort or search your dims. performance wise i doubt there is much in it, but cubes would be more flexible if that is what was required.

[Paul Coggan]

i have done spent a fair bit of time on testing the performance difference between attributes and lookup cubes when used in rules. It may not be logical but I have found that lookoup cubes are signifcantly faster. You probably wont notice the difference in a small model but if you are working with something that takes over a few minutes to calculate you will find that cube references are faster. This applies to refering to an attribute via its }element attributes cube reference in preference to the direct ATTRN method.

[Steve Rowe]

Interesting info Paul, as ever some more questions.
Were the values you referenced ruled or direct input?
Did you only test against numeric values or did you get the same results vs strings.
What version did you test in?

Cheers,

[paulsimon]

Paul

Similar question to Steve - The ATTRN is potentially odd since Numeric Attributes don't consolidate so they are not normal numbers. I would be interested to know if you get the same slow down with ATTRS against Text or Alias Attributes. I have never found much need to use numeric attributes.

Regards

Paul Simon