Re: table constraints and performance

Besides the performance issues, I think it's correct to detect refreshes
before sending data to the database.

In our applications, we ignore refreshes from the begining.
We do it by sending a serial number, which we keep on a session
variable.
Every time we send a page to a client, we increment this number, update
the session variable, and send it as a hidden within the page.
When the user submits the page (and the hidden value), we check the
serial number submited is equal to the session's serial number. If it
is, we write to the database, if it's not, we just skip the writing
code.

This way, when the user refreshes the page, the session variable always
gets incremented at the server, but the value submited is always the
same.
You can implement it in an easy generic way, and you don't waste time
sending updates to the database that you know will fail anyway.

Hope it helps :)

On Mon, 2003-08-25 at 14:44, Brian Maguire wrote:

> Could someone provide me with some information in regards to the
> performance implications of applying constraints on a table? Are there
> any safe guards?
>
> The basic scenario is that there is a table that has 80% updates and
> inserts and 20% selects. I would like to restrict duplicate inserts
> from user double clicking or other user behavior such as refresh.
>
> I am after advice on what the performance implications would be on
> placing restraints on a table vs. writing business logic code.
>
> Thanks,
> Brian
>
>
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>