Subject | Re: [Firebird-Architect] GUID Key Fields |
---|---|
Author | Jim Starkey |
Post date | 2005-03-29T18:34:05Z |
Kevin Berry wrote:
but I would like to point out that couple of upwards compatible changes
to sequences/generators could make them cluster-unique and stay within
the exiting 64 bit numeric type. This is sufficient for all database
purposes that I'm aware of, and works well with Firebird indexes, which
GUIDs don't. If there is agreement that cluster-unique sequences are
sufficient, it makes more sense to invest effort to support them than a
GUID datatype.
When you scrape through the layers of the argument, it makes a great
deal more sense to address the actual issues, cluster unique
identifiers, than to support a workaround for the absense, GUIDs.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>Re-read my statement. I didn't say it was the hardestI've stayed out of this one because it's been hashed to death before,
>part. ;-) I must say that my motivation is that I
>really love the concept of GUIDs for database keys.
>It isn't because it'll make porting to Firebird so
>much easier. But it will make it a bit easier...
>
>
>
but I would like to point out that couple of upwards compatible changes
to sequences/generators could make them cluster-unique and stay within
the exiting 64 bit numeric type. This is sufficient for all database
purposes that I'm aware of, and works well with Firebird indexes, which
GUIDs don't. If there is agreement that cluster-unique sequences are
sufficient, it makes more sense to invest effort to support them than a
GUID datatype.
When you scrape through the layers of the argument, it makes a great
deal more sense to address the actual issues, cluster unique
identifiers, than to support a workaround for the absense, GUIDs.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376