On Nov 16, 2016, at 8:46 AM, Richard Hipp <d...@sqlite.org> wrote: > >> On 11/16/16, Keith Medcalf <kmedc...@dessus.com> wrote: >> What I do not >> understand is why one would use a UUID (randomly generated bunch of bytes) >> as a key in a database. It is long, every use must be checked for >> collisions, and inherently far less efficient than the simple integer >> sequence it is replacing. > > If you use good randomness to generate the UUID and if the UUID is > long enough, then you do not, in fact, need to check for collisions. > It doesn't take an excessively long UUID to make the probability of > collision become far less than the probability of a random cosmic ray > hit on your CPU causing it to give the wrong answer on a collision
I think this discussion is about apples and oranges. UUID stands for universally UNIQUE identifier, so there won't be any collisions. It looks random, but it never repeats. Here's one: "cb058c3a-ac3d-11e6-80f5-76304dec7eb7". I use a UUID [a non-random string guaranteed to be unique -- obtained via an iOS getUUID() function call] to match records in two databases on different machines. They are records for individuals that occasionally have to be merged. The UUID is acts as a guaranteed unique name for each individual. Jeff _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
