ddoord wrote:I wonder if autohashnumber128 creates unique autonumbers for unique inputs. If not, I don't see a use for this function.
While hash functions don't usually guarantee unique results, there are lots of ways for hash tables to handle collisions. I'd be shocked if QlikView isn't using something robust. Hashing can be pretty basic.
Speaking VERY generally and with no testing and no knowledge of their internal implementation, I'm GUESSING that the advantage of hashing over autonumber isn't in space utilization (it's a 16 byte result, after all), but rather in load speed. Let's say you have a million keys in your table. In an autonumber table, these keys are numbered 1, 2, 3... 1000000. Big loads would never finish if they were just linearly searching this table every time they come across a key during the load (O(n^2) performance), so QlikView is probably using some sort of self-balancing tree with O(n log n) performance. A hash table, on the other hand, will have O(n) performance in the typical case, which is going to be faster on large data sets, and quite possibly even on small data sets due to the simplicity of hashing compared to maintaining a self-balancing tree.
I imagine the load speed difference would be negligible in most cases, though.
Perhaps I should do some testing.
