2015-12-12 22:07 GMT+01:00 Darren Duncan <darren at darrenduncan.net>:
> On 2015-12-12 12:56 PM, Cecil Westerhof wrote: > >> By the way: I am thinking about using UUID for projectID and groupID, >>>> >>> but I >>> >>>> heard somewhere that it was a bad idea to use UUID for an indexed field. >>>> >>> Is >>> >>>> this true?? >>>> >>> >>> I think you might have misunderstood. UUID is almost always a good >>> field to index. >>> >> >> ?I was told because of the nature of random UUID (what I will be using) it >> is hard to create a good index. The article said that data that is really >> random cannot be indexed very efficient. But I do not have to worry about >> it then. :-) It has been a few years back, so it is also possible that the >> problem is solved nowadays. >> > > Cecil, it isn't about randomness, it is about uniqueness or cardinality. > The fields that index the best are ones with many different values, in > particular key fields where every record has a different value from every > other record. UUIDs have this quality in spades. It is even more important > to index such fields if you will either be searching/filtering on them or > if they are the parent in a foreign key constraint. This has always been > the case, its not a new thing. > ?That was what that (old) article said: because the data was completely random it was hard to create a balanced tree for the index. I did find it a little strange, but I am not an expert on creating balanced trees for an index. But again: I am happy that it is not a point. -- Cecil Westerhof
