From: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
---|---|
To: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
Cc: | PostgreSQL general <pgsql-general(at)postgresql(dot)org>, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
Subject: | Re: *****SPAM***** Re: UUID column as pimrary key? |
Date: | 2011-01-05 17:48:37 |
Message-ID: | 99698C36-E3AE-4277-9DF6-8C7F81E690DF@elevated-dev.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Jan 5, 2011, at 10:30 AM, Radosław Smogura wrote:
> 128bits is huge for now, but what will happen in next 2,3 years?
It will still be large. When you get up to around 100 trillion UUIDs, you'll be getting up to around a 1 in a billion chance of a single collision. Before you claim that we'll outgrow them in a few years, you might want to consider the actual numbers, the growth rate of storage density, the number of disks required to hold that many records. I have a feeling the answers might surprise you ;-)
> If we want to guarantee uniquness of UUID across calls, we could talk about
> much more far _pseudo_ random generator, then "normal" pseudo - randoms, and
> what I think we need to keep state of such random generator, and share and
> lock it for multiple concurrent calls. So it will not be something different
> then ordinal serial column...
No, we don't really have to think about it much at all. The IETF and OS engineers already did. Random UUIDs are not generated with some sloppy amateurish algorithm.
> My opinion about all of those UUID with MAC, IP addresses, Microsoft "growing"
> UUIDs. All of this decrases chance of uniqness of UUID.
Well, a decrease from one insanely small chance to another insanely small chance is not anything to worry about. After all, you could argue that 128 bits is a "decrease" from 256 bits. It's the same argument. UUIDs were designed to avoid collisions, by people who knew what they were doing. More significant bits would lower the chance, from "already low enough" to "even more low enough".
> Shouldn't this be enaugh for namespace UUIDs
> new UUID("namespece".hashCode(), "name".hashChode())
>
> or a little joke...
> new UUID(1,1) meats this condition
>> o The UUIDs generated at different times from the same name in the
>>
>> same namespace MUST be equal.
>
People, people, people, please. *Namespace* UUIDs are intended to map *unique* names to UUIDs in the case where you already have *unique* names and just need to map them to a more compact form, thus the requirement that the same namespace + name always yields the same UUID. This is *not* a weakness in UUIDs, nor is it the kind of UUID you get from a simple uuid_gen or similar call, nor is it a possible source of collisions for database UUIDs (unless you do something enormously stupid, like use database fields to construct a name to give to a UUID generator).
--
Scott Ribe
scott_ribe(at)elevated-dev(dot)com
http://www.elevated-dev.com/
(303) 722-0567 voice
From | Date | Subject | |
---|---|---|---|
Next Message | Вячеслав Блинников | 2011-01-05 18:04:43 | Asynchronous queries with callbacks. |
Previous Message | Filip Rembiałkowski | 2011-01-05 17:37:43 | Re: How can I get the list of index(or other objects) which depends on a function |