Subject Re: [Firebird-Architect] GUID Key Fields
Author Alexandre Benson Smith
Hi Jim,

Jim Starkey wrote:

>I've stayed out of this one because it's been hashed to death before,
>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.
>
>
>
Sorry I don't follow this list for a long time, I don't know what was
discussed about clustered unique identifiers.

I think mos people uses GUID/UUID for distribuited databases, to ensure
unique identifiers across any DB. The use of generators (in the actual
stage) does not provide it, I saw some diferent approach to achieve this
using generators:

1.) Add a "Site ID" and make a composite PK's with a simple generator, I
don't like composite PK's

2.) Define intervals for each site, that lead to manual intervention
when the values exausts

3.) Use steped values (don't know how to call this), for example one
defines a limit of 1000 sites (individuals DB's), the generators values
will be started with an off-set and increased by 1000 so for site 1 the
values wil be 1001, 2001, 3001, 4001 for site 2 will be 1002, 2002,
3002... for site 999 will be 1999, 2999, 3999 and so on. This is my
prefered approach, since the numbers will just increase to the limite of
a int64 and will not required human intervention, the contra is one have
a limited numbers of individuals DB's, in my systems a gap of 1000 is
far away what I expects to reach, I expect a maximum of 10 individuals
DB, so a 100x bigger gap make me fill comfortable :-)

4) Uses UUID/GUID. I thought the more versatile way to handle this,
since no interval should be defined, no gaps are fixed, no human
intervention to make things run smoothly, the contra a very big number,
hard to type even in hex form

5.) Cluster unique identifiers....

Do you mind to explain what is this, how do you think it will work or
point some thread where it was discussed ?

If this ensure a unique value accross multiple unconnect DB's, I will
agree that we don't need anything else.

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.1 - Release Date: 23/03/2005