PBI Performance when using string instead of numeric for relation keys

[FilipK]

This question is derived from a former problem of mine. 

Due to rounding problems in PBI I was not able use a big numeric (16 digits) as a key to connect to other tables. (Solved: Re: Typecasting and Accuracy for index columns - Microsoft Power BI Community)

I've recently found out there there might be never a solution for it (Solved: Re: Unexpected long numbers round in Table visual - Microsoft Power BI Community)

I expect if I change the datatype to varchar/string instead of numeric that the quering performance will be much worse and the dataset is increasing a lot (2 Mio rows with 16 character keys instead of 16digit keys). What is your opinion on that? Is there a nicer way to overcome the initial problem without reducing performance and increasing dataset size?

[lbendlin]

There is no easy answer to this - you need to try it .  Keep in mind that the Vertipaq engine uses columnar compression, so the cardinality of your columns plays a bigger role than the size of the columns.

[FilipK]

I see. I'll try. I can choose two use 20 character long key (comes from concat two strings) or to use the hashed value of they string. Is there any advantage in hashing it?  Assume both methods create a 20byte value. Is there any performance advantage one can expect using the hashed value?

[lbendlin]

Leave the hashing decision to the engine.

[FilipK]

PBI doesn't make it easy... Hashing creates binary, so I need to convert that before to mmmh, I'd say only string is possible, since when changing it to numeric I end up in the same situation as before...

And if I convert it to string, that I don't need to hash it. Instead my string I hahsed is sufficient for it is unique already.