If you must use an UUID generator instead of a PK generator, use the algorithm you linked to, but use just time and the randomizer. Your EJBs should be wrapped in a façade anyway, so if there is a key collision catch the exception and generate a new key.
Or you could use a compound key, part of which is the generated key and part which uses meaningful data from the object.
I can't speak to the performance of FB indexes, as I don't know what their underlying implementation is (the FB bible is in the mail). At some point it has to actually compare the key, and string compares would be slower than long compares.

-----Original Message-----
From: rajsubramani [mailto:rajsubramani@...]
Sent: Monday, August 16, 2004 6:07 PM
To: Firebird-Java@yahoogroups.com
Subject: [Firebird-Java] Non-numeric primary key

I am developing an application in JBoss with Firebird as the
datastore.

I am toying (at this initial stage) between numeric primary keys and
string based primary keys.

The latter because I could used a uuid generator within my EJB
(http://www.activescript.co.uk/jguid.html) to get a (almost) unique
key (in both space and time).

However, after a lot of "google" searches I have yet to understand
conclusively whether a numeric PK would be more "efficient" to index
as opposed to a varchar(36) key (particularly when the DB has between
100,000 to a millon records to sift through).

I would appreciate your thoughts on this matter (and also if the
argument would apply to most RDBMS's).

Cheers
-raj





Yahoo! Groups Links