Sean wrote:

> Hi,
>
> I found that the speed of queries can be very slow when the database
> is intensively updated/inserted. To maintain reasonable UI response
> that heavily depends on query speed, I am thinking to split the
> database into two, one for update, one for query. Then periodically,
> e.g. every minute, sync the changes from updated database to query
> database.
>
> 1. Is this a good idea? Or are there other options?
>
> 2. Can someone please suggest on how to do it?
>
> Thanks a lot!
> Sean
>

Sean,

You should have a good response even if the database are "heavily" updated.

The most important factor is to keep your transaction as short as
possible, remember that reads run inside a transaction too, so open
transaction, read the values, close transaction, open transaction,
update/insert/delete, close transaction.

Put your database statistics when you consider the select time are slow
so we can look how you are dealing with your transactions.

If you have the necessary indices and a good transaction control, your
database should be pretty responsive.

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br