At 06:39 PM 4/26/00 -0700, David Berg wrote:

>I was talking to an Oracle rep today who mentioned that 'all databases
>(except RDB) have indexes that get out of sync and must be rebuilt
>periodically.' He then went on to talk about a new feature in Oracle that
>allows indexes to be rebuilt while the database is still in use.
>
>While I found the feature interesting, I was amazed at the statement. I
>can't imagine a database allowing an index to 'get out of sync', because to
>me that means queries that use that index won't be reliable. I truely hope
>that he just meant that the indexes get slow/fragmented and need to be
>rebuilt.
>
>Does anyone know if this is true (for Oracle or others)? Does Interbase
>suffer from such problems: fragmentation or inaccuracy (given it's history,
>I would expect that it works more like RDB)? Do we need index rebuild
>facilities in Interbase? Or can we market it as more reliable than
>Oracle!!!
>

It's probably true but not as important as you might think. It is
straightforward to ensure that an index reflects all committed records,
but more difficult (and ultimately pointless) to guarentee that the
index doesn't contain unbacked out stuff.

The answer for Interbase is contradictory. Yes, the index
is decoupled from the table, but no, it doesn't make any
difference.

Because Interbase is multigenerational, several versions of record
must reside in the index simultaneously, even if the index is
"unique". Accordingly, Interbase treats the index as noisy;
when a record is fetched by index (which almost always happens
indirectly through a sparse bit map), Interbase re-applies the
full boolean restriction before deciding the record is a keeper.

Jim Starkey