>Yes, but that does not tell you which cluster node it belongs,
>does it?
>
>
>

Why not ?
If you use the "Old Style"UUID part of the number will be the mac
address, so you know the cluster node.

There is no need to to have 2 * UUID to get this.

>That is why I suggested a pair of UUIDs.
>
>
>
>>256 bits is a very very big key, the indices will suffer
>>this choice.
>>
>>
>
>Last time I checked 256 bits equalled 32 bytes.
>
>

And I am sure it was 32 bytes in the past and will remain in the future ;-)

Anyway 32 bytes is just twice 16 bytes, that is half index entries per
page, don't you think that if you can have half indices entries per page
for nothing will be a VERY big penalty ?

>Why is this such a big problem?
>
>

Waste of I/O

>Even though I too can not pronounce words that are
>32 bytes/chars long, I am sure Firebird/Vulcan can
>handle that.
>
>
>

for sure, but what is the benefit ? I think I didn't got it.

>Plus, Jim keeps reminding us that RAM is free as opposed
>to 640 K being enough for anyone.
>
>
>

For sure, but I/O is not free halfing the indices entries on a page for
no gain makes no sense to me, but perhaps I am missing some important point.

You could even use 4 UUID to compose your PK:
1st to identify wich cluster it is
2nd to identify wich node inside a cluster
3rd to identify wich table it belongs
4rd to identify wich row on that table

And I am sure some one could point a bunch of more things that could be
"identified", but IMHO it's not necessary, a single UUID will identify
something (be it a record, an interface, or else) unique in the world
for a long time. if you wish to identify the node ID outside the UUID
context, I'd prefer to use an integer field and populate it with the
NodeID that was stored somewhere. If you use a UUID to identify a node
id you will repeat this number (that should be fixed for a node right ?)
in a lot of records, you will just have a 128 bit field to store a range
that a 16 bits will be enough.

>Cheers,
>Adem
>
>

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.5 - Release Date: 29/03/2005