https://en.wikipedia.org/wiki/Birthday_problem
In probability theory <https://en.wikipedia.org/wiki/Probability_theory>, the *birthday problem* or *birthday paradox <https://en.wikipedia.org/wiki/Paradox>*[1] <https://en.wikipedia.org/wiki/Birthday_problem#cite_note-1> concerns the probability <https://en.wikipedia.org/wiki/Probability> that, in a set of {\displaystyle n}[image: n] randomly <https://en.wikipedia.org/wiki/Random> chosen people, some pair of them will have the same birthday <https://en.wikipedia.org/wiki/Birthday>. By the pigeonhole principle <https://en.wikipedia.org/wiki/Pigeonhole_principle>, the probability reaches 100% when the number of people reaches 367 (since there are only 366 possible birthdays, including February 29 <https://en.wikipedia.org/wiki/February_29>). However, 99.9% probability is reached with just 70 people, and 50% probability with 23 people. These conclusions are based on the assumption that each day of the year (except February 29) is equally probable for a birthday. UUID https://en.wikipedia.org/wiki/Universally_unique_identifier Out of a total of 128 bits, Type 4 UUIDs have 6 reserved bits (4 for the version and 2 other reserved bits), so randomly generated UUIDs have 122 random bits. The chance of two such UUIDs having the same value can be calculated using probability theory (birthday problem <https://en.wikipedia.org/wiki/Birthday_problem>). Using the approximation To put these numbers into perspective, the annual risk of a given person being hit by a meteorite is estimated to be one chance in 17 billion,[5] <https://en.wikipedia.org/wiki/Universally_unique_identifier#cite_note-5> which means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a* few tens of trillions *of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. ------------- Generating a recordset on client side - you'll have that ID in one place, if it needs to change (on insert fails) you generate a new one and insert again - everything else is likely related to that first field in the first place. If it's a case of merging datasets - how many of a type of record are you really generating? 4? 5? if it's a generation of millions of opints - than probably there should be a different unique ID associated that increases them to a full unique uuid space each. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
