> >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.

Other people have already highlighted the problems
associated with relying on the MAC number.

While I personally am not that worried about the security
issues, I would be concerned about the cases where there
are more than one NIC on the box.

OK. This is not an unsurmountable issue since one
can assign MAC addresses to the NIC. Yet, this alone
is potential for headaches. Why mess with that sort
of thing; it is worse than having duplicate IP nmbers
on the LAN.

So, all in all, I feel it is not worth the risk. Of
course, this is a non-autheritative personal opinion,
as eerything else I write :-)

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

Yes, but all others are non-sandard hacks, aren't they?

> 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 ?

True, it is twice as long, but think of the overall
convenience. You could have all the worlds CPUs as
your cluster nodes and not worry about address space
ever again for the next XXXX years.

> >Why is this such a big problem?
> >
> Waste of I/O

This is merely a hardware issue. Quoting Jim out of
context --again--, hardware problems need to be solved
at the hardware level. Isn't it wiser to get a faster
network or faster box with a faster I/O rather than
crippling the design (or downdesigning) at the
architectural level.

> >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.

Extensibility. Design now and never worry about it
for the next millenia?

> >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.

It is probably more likely that I am missing something
too.

I would like to know how significant this would be
as far as I/O is concerned.

Something tells me (and these are the times I hear
voices in my head ;-) ) that it should not be that
significant.

> 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

I suppose you could.

> 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.

These are all valid points --especially at this time
when cluster stuff rarely used and we dont really know
what's in store a few years down the line.

In defence of my points I can say these:

Take for example IPv4. While I am garteful that they
realized soon enough it would not be sufficient to
use, say, IPv2; I would be even more grateful if they
thought far enough into future and foresaw the need
for IPv6.

Another point for UUID for cluster address is their
guaranteed uniqueness. It means CPUs can come in and
go out without disturbing much.

Then there is the implicit versioning aspect of UUIDs;
which I have no idea how to apply in terms of clusters,
but it is there.

All in all, I would like to err on the side of
expandability.

Cheers,
Adem