On 17 Nov 2016, at 3:13am, Keith Medcalf <kmedc...@dessus.com> wrote:
> You would only get guaranteed collision avoidance if you kept track of every > UUID issued and checked for duplicates at time of issue to avoid duplication > by keeping a list of all the "used" identifiers. I do not think that keeping > track of all the UUIDs issued to avoid duplication is part of the spec. They > really should be called SRID's (somewhat random identifiers). The randomness is not part of the intended spec for UUIDs. The emphasis was on the 'Unique', which is why the name had 'U' in, not 'R'. The first form of UUIDs combined the IP address of the originating computer with the time in .1 microsecond intervals. The assumption is that no computer would be fast enough to need to name two entities in .1 microsecond. Thus UUIDs would be inherently unique without needing any extra programming or needing to consult a database of already-used UUIDs. This was considered very clever. But this scheme was criticised for giving away too much information. For instance, if you saw a UUID for a car part you could immediately deduce the IP address of am important computer belonging to the car company. That could be a good target for hacking attempts. So number of other options were thought up, one of which can easily be created from a URL, one which relates to a domain name, some of which were designed from the outset to have the properties of random numbers. It was a random-looking scheme -- known as version 4 -- that I mentioned which set off this thread. Because it looks random it gives away nothing about the originating device, and people like that these days. But perhaps version 1 UUIDs might suit the OP better. So yes, randomness is important to the particular type of UUID we're discussing here. But it's not essential to all UUIDs. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
