> Do you understand the implications of using a string as a primary key?

Do you mean a string in particular or a GUID?

As far as using a string, it does not make a lick of different what
datatype is indexed as far as performance goes.

http://www.ibphoenix.com/main.nfs?page=ibp_expert1

<quote>
Firebird converts all index keys into a format that can be compared
byte-wise. With the exception of 64bit integer fields, all numeric and
date fields are stored as double precision integer keys, and the
double precision number is manipulated to compare byte by byte. When
performing an indexed lookup, Firebird converts the input value to the
same format as the stored key. What this means to the developer is
that there is no inherent speed difference between indexes on strings,
numbers, and dates. All keys are compared byte-wise, regardless of the
rules for their original data type.
</quote>

The GUID field is a reasonably large size for a PK, so I suppose you
should consider things like database size and required bandwidth, but
as I said in my original post, you are still below the 250ish byte
limitation of Firebird 1.5 for index size, and well and truly below
any 1/4 page size limit of Firebird 2. I suppose the index itself will
be a bit more sparse too.

I can see some useful reasons for using a GUID, particularly for
distributed systems where it is not practical to source keys from a
single generator. It saves the effort of a key translation later when
synchronising changes. You simply pump in the new records, and remove
the records flagged as deleted, and deal with updates however your
business rules require.

But as Alan has pointed out, and as anyone who has ever had to
manually activate windows knows, it is a real pain to type in a long
string of characters, so this should be weighed up.

I never use anything as a primary key that has real world
significance. As soon as you do, you end up having to change PK values
and then get the inevitable problem of triggers firing and waiting for
the FK values to cascade. I prefer a simple domain defined as either a
BIGINT or INTEGER, not null, fed by a generator. That way I can look
for record 195931 instead of record
'{6EB22381-8AB9-12D0-81B7-00ABC9231C29}'

Adam