Subject | RE: [IBO] TIMESTAMP question |
---|---|
Author | Helen Borrie |
Post date | 2004-12-10T11:39:23Z |
At 12:17 PM 10/12/2004 +0200, you wrote:
a RDBMS likeFirebird, your primary key does not determine the storage order?
You can (and should, in dynamic tables) use a primary key that has no
meaning as data. Any field that you need to order by in queries can be
indexed, if it is sensible to do so. However, the db engine does not need
indexes in order to sort or search; and keys are not indexes (although
they do have mandatory indexes to enforce them).
Helen
>Thank you Helen, I'm well aware of the fact that using the client's time isDo you know about generators and primary keys? Do you understand that, in
>never good practice. This project is currently only a proof of concept and
>for now the software will always run on the same machine as the Firebird
>server. I personally also didn't like the idea of using a floating point /
>timestamp value as a primary key but I just don't see an easy way around
>this. At first I used two separate integer fields (Delphi's TDateTime
>integral and decimal parts split-up) but that causes difficulty in sorting,
>so I ended up going the TIMESTAMP route. Now that you mentioned that the
>timestamp on the server always returns zero milliseconds I might have to
>start re-thinking the DB design.
a RDBMS likeFirebird, your primary key does not determine the storage order?
You can (and should, in dynamic tables) use a primary key that has no
meaning as data. Any field that you need to order by in queries can be
indexed, if it is sensible to do so. However, the db engine does not need
indexes in order to sort or search; and keys are not indexes (although
they do have mandatory indexes to enforce them).
Helen