Helen,

did I misunderstand you (as is likely,) or did you suggest that the "rule" is that primary keys
shouldn't contain any meaningful information? i kinda thought it was the other way around ...
although our own project -does- use generators for primary key values, i've often been reminded
that in theory, you really should be using some unique property of the data itself, in the form of
a candidate key, when selecting a primary key ... the theory also continues, saying that an index,
under any form, should not be required to enforce uniqueness properties: you should be able to
define a primary key on any field, regardless of how your index works, as the PK is a logical
thing, and the index is a physical thing (increasing access speeds.) the optimizer should, if at
all possible, be invisible on the logical level.

but then, i've been told firebird plans to remain an SQL database, not a relational one ...

-philip

> 3 * 25 characters of meaningful data doth not a good primary index make,
> regardless of the size limitation. Apart from breaking the golden ACID
> rule of making all keys free of any meaning as data, your PK will slow down
> joins and referential integrity triggers. Under many conditions, it will
> mess up the optimizer as well.
>
> You are far better to make a surrogate primary key, using a generator and
> triggers to make it auto-incrementing. This will solve the size limit
> problem for the key and also prevent clutter in your foreign key and join
> criteria bindings. Provide separate indexes with collations for each of
> those key elements for use by the optimizer in searches and sorts.
>
> You can place a UNIQUE constraint on the three columns WITHOUT COLLATIONS,
> to prevent duplications.
>
> Helen