On Wed, May 20, 2015 at 7:20 PM, R.Smith <rsmith at rsweb.co.za> wrote:
> > On 2015-05-21 01:52 AM, Peter Aronson wrote: > >> Now you're just getting silly. What if the application sets all rowids, >> everywhere to 1? The fact is, the chance of collision on a UUID is pretty >> astronomically low as long as a decent source of entropy is used (see >> http://en.wikipedia.org.... >> > > I think Keith's point (which I very much agree with) is that > astronomically big is still not guaranteed - and ANY solution that relies > on something not guaranteed is a bad solution. I'd much rather even ensure > that similar ID's are used client-side, then KNOW that that is the case and > implement a solution that understands this and deals with it (such as > simply prepending a device-specific ID or some such) to ensure 100% secure > uniqueness server-side - no need to rely on astronomically big > randomnessessess. > Then I guess all the distributed version control systems that rely on unique hash values (including fossil, the sqlite DVCS) are a bad solution. Note that two of the five defined standards for UUID are based on hashes. Okay, so modern hashes are longer than 128 bits, but that only reduces the probability of a collision, it does not eliminate it. "But that's not used as the primary key of a SQLite or other relational table" you might say. Except it is the unique key for a conceptual table. Certainly I do not agree with the originally linked article that integer primary keys should almost always be avoided, and there was a lot of exaggerating in the risks involved. Still, UUIDs (or other similarly long or longer hash or quality random number source based IDs) can be an effective technique when used appropriately. -- Scott Robison
