--- In firebird-support@yahoogroups.com, "burmair" <YahooSpam@...> wrote:

>
> Hi,
>
> I have to update a DB with a lot of small changes (usually updates,
> but sometimes inserts and deletes). The changes are not usually
> logically related, but sometimes they are, especially for deletes. In
> terms of performance, is it faster to do as much as possible in a
> single transaction (or maybe a few "chunks"), or is it essentially the
> same if each update is performed in its own transaction?

Use a separate transaction when the work is unrelated. Use the same
transaction when the work must be atomic (all or nothing).

What factors

> might make a difference? The size of the rows in question?

For inserts obviously, updates it would depend on the amount changed.

The

> number of rows in the tables?

Shouldn't

> The mix of update/insert/delete?

updates and deletes create record versions which must be garbage
collected at a later time, so only update or delete records that you
want to (there was a post a few days back where someone was deleting
records only to reinsert them).

> Cache size?

Yes.

>Forced writes?

Yes, but if you care about your data this is non negotiable.

> Indices?

Absolutely. Massive benefit to some selects, slight penalty for
everything else so design with respect to how you anticipate the data
to be used.

Adam