From:
                                                            22.01.1998 21:22
Subject: Re: RDB$DB_KEYTo: INTERBASE@dx100.mers.com

At 01:07 PM 1/22/98 -0500, Gregory H Deatz wrote:

>select rdb$db_key from foo
>
>will return a transaction-unique identifier for each row in the table foo.
>Using the row unique identifier, I can execute the following statement:
>
>update foo
>  set bar = "foobar"
>  where rdb$db_key = ?,
>
>where the ? is filled in by a value returned from the above select
>statement.
>
>If there are a small number of rows in the table, the update statement will
>work *very* quickly.
>
>But what if there are millions of rows? Is the rdb$db_key an _indexed_
>value? Does it gain me immediate access to a given row? Or will IB scan the
>table until it gets the right rdb$db_key?
>

It's better than indexed.  The rdb$db_key value contains the pointer page
number and offset and the page index offset for the row - it is the record
pointer stored in the index.  There's no scan involved.  For the database,
the rdb$db_key is the fundamental record identifier - as long as that record
exists, it will have that identifier.  Programs must treat it as transaction
specific* because the record could be deleted, garbage collected, and a
new record stored in its place.  Since the rules for garbage collection
preserve any row a transaction can see, as long as your transaction lasts,
the rdb$db_key will take you to the same record.

In case it got lost in the drift, the rdb$db_key is by far the fastest
way to get to a particular row - faster than an index.

Good Luck,

Ann

 (*) or attachment specific if you can get at the attachment
(connection) option that preserves rdb$db_keys -