> IMHO if it does not support transactions, it is NOT a database.
> I have several times implemented a collection of indexed files,
> in various languages & o/s's, but that is NOT a database,
> unless it also supports transaction logging, transaction backout
(rollback),
> and transaction integrity i.e. the application level can define an
indivisible
> unit of work which is either done or not done in its entirety,
> (or at least appears that way to other tasks),
> which may comprise multiple adds/updates/deletes.
> (I've also implemented that once, in COBOL !!!)
>
> Not wanting to start a flame war, I am genuinely mystified, as
> in my understanding transactions is the essential feature
> which sets real databases (Oracle, Progress, Sybase, PostgreSQL, etc)
> apart from "a collection of indexed files".
>
> In business databases, a simple transfer between 2 accounts is typically :
> begin transaction
> add rec acct1 with -amount and new balance
> add rec acct2 with +amount and new balance
> end transaction
>
> How would this be done in MySQL without transaction support ?
Ah this is always a problem on the MySQL mailing list. Not including
transaction support was a concious decision made by the MySQL developers in
the interests of speed basically. They felt because of the overheads
required to do transactions, MySQL would loose its edge when it came down to
speed. The upshot of this is that you have to do transactions in your
programmign which is a nasty kludge.
Transaction support is coming up in MySQL and you'll be able to specify at
which level you'd like transactions i.e. across the DB or on individual
tables. That means you can read from one table just as fast as normal and
use transactions on another table. Quite cute.
BTW: Postgres has got some nbew features coming in 7.0. They're having a
crack at foreign key support amongst other things.
Cheers,
Graeme
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
