Comments on: If you only learn one thing about database transactions, it should be this

By: Rue Plumet » Interesting Sites For This Week

Rue Plumet » Interesting Sites For This Week — Mon, 04 Sep 2006 02:37:52 +0000

[...] If you only learn one thing about database transactions, it should be this Tagged as: database design [...]

By: Nate K

Nate K — Mon, 28 Aug 2006 13:38:56 +0000

This is a great list. I think its overlooked by many that work with databases. Your comparison of 'running out into the rain' hit the nail on the head for me. Get in, get your work done, and get out. It shouldn't be a trivial process.

By: Xaprb

Xaprb — Mon, 28 Aug 2006 12:44:48 +0000

James, that’s a great addition. Peter, I agree. I actually advised a client to go this way recently — store incremental updates into a staging table, then apply updates from the staging table every ten minutes. It helps him get some more benefit from the query cache, too. We actually experimented with a good batch size at my employer when I was writing our archiving and purging jobs (see past articles), and found 1,000 rows worked very well — it is small enough that it doesn’t block much, but it isn’t constantly trying to flush things to the disk either. It was many hundreds of times faster than a row at a time. So — when I say “as small as possible” I don’t mean a row at a time, I mean don’t do unnecessary work.

By: Peter Zaitsev

Peter Zaitsev — Mon, 28 Aug 2006 12:01:46 +0000

Keep you transactions as small as possible is something I would be careful with. I've seen people doing 1.000.000 transactions to insert 1.000.000 rows. It is not smart ether as commit overhead is going to be significant.

If you have batch operations medium size transactions are best, so commit overhead is not going to hurt you while you're not possibly blocking things for a lot of times due to locks :)

By: James Day

James Day — Mon, 28 Aug 2006 10:36:26 +0000

One other thing you can try is ensuring that the data is in the database server cache with a select outside the transaction. Adds to the general server load so it's mostly of interest in areas where contention is greatest, not as a general design rule.