| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Reformatting GUIDs
Charles Hooper a écrit :
> hasta_l3_at_hotmail.com wrote:
> > Charles Hooper a écrit :
> >
> > > Vladimir M. Zakharychev wrote:
> > > > Charles Hooper wrote:
> > > > > I wonder if you can look at this from a different direction. What if
> > > > > you use the random number generating capabilities to generate each of
> > > > > the hex numbers between the dashes?
> > > > >
> > > > > For example, the second section of the GUID contains a four character
> > > > > hex number. If you have Oracle provide a hex number between hex 1000
> > > > > and hex FFFF, that would be sufficient to satisfy that portion of the
> > > > > GUID. If you pre-convert the hex numbers to their decimal equivalents,
> > > > > you will save Oracle a little work, but it will be more difficult to
> > > > > see what is happening.
> > > >
> > > > The only problem with this approach as I see it is that use of
> > > > DBMS_RANDOM will probably have adverse effect on "GU" part of the
> > > > "GUID" (GU = Globally Unique.) SYS_GUID() guarantees that all returned
> > > > values are globally unique, because afaik it uses system timestamp and
> > > > unique host information for GUID generation, among other things.
> > > > DBMS_RANDOM doesn't guarantee uniqueness of returned values, only
> > > > randomness.
> > > >
> > >
> > > I am not disagreeing with you, but I believe that the random number
> > > generator in Oracle can be seeded with the system time. The reason
> > > that a GUID is thought to be unique is due to the range of possible
> > > values, essentially 15 * 16^31 (or if the first digit can also be a 0,
> > > 16^32, or 16 * 16^31).
> >
> > Yes and no, Charles...
> >
> > UUIDs are usually globally unique because they identify a single point
> > in space-time - that is they are essentially a concatenation of
> > system time and node MAC address.
> >
> > You are correct in that a variant uses a random generator (which must
> > be of cryptographic quality) , but note that even this variant has a
> > well
> > defined internal structure, that is required for a true uuid.
> >
> > > Note that there is nothing stopping the OP from calling sys_guid() five
> > > times, each time extracting a different sub-string portion of the value
> > > returned.
> >
> > Well, I may be wrong but I have a feeling that the OP may generate
> > the same identifier twice with this algorithm, if mischance wants that
> > a sub-string of the guid system clock component overflows...
> >
> > BTW, if you are interested, the RFC on the subject is here :
> > http://www.ietf.org/rfc/rfc4122.txt
> >
> Raoul, thanks for the link. It looks like there is more order to a
> GUID than I originally thought.
>
>
>
>
Are we talking of randomly generated uuids, Charles ?
Such uuids have 122 random bits, that is ~ 1E+36 different values. At the rate you have choosen, we would need 1E+14 years to exhaust them - a pretty confortable margin :-)
However, we should compute the probability of a collision with the Birthday Paradox. Assuming a uniform generator, a collision is pretty probable for ~ Sqrt(1E36) = 1E18 generated uuids. At the rate you have choosen, we should expect a duplicate every hour or so !
That's so surprising that I cannot help but think that I've messed up my maths somewhere. On the other hand, being surprised is the essence of the Birthday Paradox :-)
Please feel free to critize, Charles. Perhaps in private, because we are now waaay off topic....
Best regards
http://en.wikipedia.org/wiki/Birthday_paradox Received on Fri Dec 22 2006 - 02:55:12 CST
 |
 |