I've had a look through BOL and countless sources but I can't find an
answer to a question that has been troubling me....

Is there anything to be gained from restructuring the keys of my
dimensions to be as small as possible in the fact table or does
Analysis Services do something funky to make this a waste of time?

Example:
A customer dimension currently with a CHAR(12) key would join to the
fact table on this CHAR(12) field. So each row of my fact has a
wopping CHAR(12)in it.
However, presumably if I create a pseudo key on the dimension of an
INT and use this in the fact table then I would cut the size of the
dimension key in the fact table by two thirds.
I'd have both the pseudo and real key, (they may want to see the
customer code), in the dimension making it 4 bytes bigger per record
but the fact table will be 8 bytes smaller per record and should be a
lot faster.... (especially if I've got 10 dimensions like this!)

Am I barking up the wrong tree? Does the size of your source fact
table and dimensions in the SQL DB have any effect when it comes to
the Analysis Services files themselves? I don't want to increase the
complexity of my transformations if I don't need to...

Any thoughts would be appreciated,
Cheers,
L

It's best practice to use surrogate keys for issues such as slowly
changing dimensions.
Sure your cube will process faster even if there is more time updating
the fact table by using lookup tables.

Regards,

John

www.johnkeeley.com



laurence_hoff (AT) hotmail (DOT) com (Laurence) wrote in message news:<ba0450c0.0405241440.5e9e7f7 (AT) posting (DOT) google.com>...