> > > I guess my question really is, how much overhead is there in the setup
> > > and teardown of a transaction, and will that overhead be affected by
> > > any of the DB parameters that I can manipulate?
> >
> > A unit of work is what you want to have saved in the database so
> > that no information is lost between the different saves. You should
> > be able to go from one consistent state of saved data to another
> > by performing calculations/adding new data/whatever.
>
> I agree. My question is, what do you do when the size of that unit of
> work exceeds the capacity of the DB to handle it as a single
> transaction? Even if atomicity can't be achieved, there are numerous
> other advantages to using a relational DB for persistence, so it seems
> like the answer would be to use multiple transactions as effectively
> as possible. Hence my question: a smaller number of larger
> transactions, or a larger number of smaller transactions?

If your transaction cannot be handled by the db system, there are
multiple things you can do:

- state your case with the developers (in the case of open source systems
like Firebird, this is very easy to do) so the problem can be solved

- try to work out another way of doing things. Being multiple transactions,
different ways of doing what you're doing now, asking for advice on
how to do things (which can only be answered in a decent way if you
describe -exactly- what you're doing)

- select a database system that CAN handle your specific needs



Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com