>The GUID algorithm that I am familiar with changes the first byte
>for each new id, greatly reducing the effect of prefix compression.
>Less compression -> longer keys -> fewer keys per page -> deeper
>indexes -> worse performance.

How can this performance be compared over a NUMERIC(18,0)? Is it a
drastic performance hit? Or can we assume that a benefit of a GUID
overrules the performance hit?

Mmmm a UID is based on networkcard number and datetime of the system.
Correct? If we're sure the networkcard number is always the first
byte, then this one is always the same. This could be done by
reversing the GUID if the GUID is based on time+networkcard number.

But thinking further... If we create the GUID on the interbase
server, then the only difference in the number is the time value. So
this would give us problems with simultanious connections, since the
time value could be the same. (cfr answers on my previous mails
telling that using timestamp isn't such a good idea)

So a GUID key is only correctly useable where the clients create the
GUID... and not the server itself...

Am I correct here?

Thanks in advance,
Tom