>
> -----Original Message-----
> From: firebird-support@yahoogroups.com

[mailto:firebird-support@yahoogroups.com] On Behalf Of Helen Borrie

> Sent: Tuesday, July 18, 2006 9:50 AM
> To: firebird-support@yahoogroups.com
> Subject: RE: [firebird-support] UUDIs/GUIDs and problem with uuidlib
>
>
> At 11:17 PM 18/07/2006, you wrote:
> > >
> > > -----Original Message-----
> > > From: firebird-support@yahoogroups.com
> >[mailto:firebird-support@yahoogroups.com] On Behalf Of Daniel Albuschat
> > > Sent: Tuesday, July 18, 2006 8:02 AM
> > > To: firebird-support@yahoogroups.com
> > > Subject: Re: [firebird-support] UUDIs/GUIDs and problem with uuidlib
> > >
> > >
> > > 2006/7/18, lutterot <lutteroth@...>:
> > > > Hello!
> > > >
> > > > I need to use UUDIs/GUIDs as primary keys in my DB and was trying to
> > > > generate/convert them with the uuidlib UDF library available on
> > > > IBPhoenix.
> > >
> > > Don't do this. It's fine to have a UUID as a separate, unique field
> > > but having it
> > > as a primary key is not good, not at all.
> > >
> >
> >Because...?
>
> Not guaranteed to be unique. But I wouldn't stress the "uselessness"
> of UUID/GUID as a unique key as hard as Daniel does. If you're
> generating it from a trigger, you just need to include a fallback
> that grabs another one if a duplication is encountered.
>
> ./heLen
>

Yeah, I suppose. The RFC seems to imply otherwise, though:
"A UUID is 128 bits long, and can guarantee uniqueness across
space and time." and "As a result, the UUIDs generated according
to the mechanisms here will be unique from all other UUIDs that
have been or will be assigned." (http://www.ietf.org/rfc/rfc4122.txt
if you're interested.)

I'm not enough of a mathematician to verify these claims, but

1) for a version 1 UUID, the time portion will wrap sometime around
3400 AD, by which time either my machine or I will have expired
and so I expect someone else to worry about it, and
2) with a proper clock, 10 million distinct UUID's per machine can
be generated per second, so a database on a machine that
generates its own UUID's probably can't request them fast enough
to get duplicates. If the clock doesn't have sufficient precision,
this could be an problem.
3) A badly assigned (duplicated) MAC address could be an issue, I guess,
but then many other things would break.

So I'm thinking its safe enough<g>.

A colleague just related a story wherein an internal Oracle generator
overflowed after about a year, causing no end of grief and consternation,
so I guess it's a problem for any monotonic counter eventually.

The thing I like about the UUID instead of the generator sequence is
that there's no generator, so I can move stuff wholesale to another
database instance without getting duplicates (unless they really
are duplicates) and not have to worry about what the generator's value
is.


Michael D. Spence
Mockingbird Data Systems, Inc.