Joe D <j...@cws.org> писал(а) в своём письме Mon, 06 Jun 2011 00:57:51 +0600:
> Non-transactional is by definition not atomic. > > With the single exception of something that is strictly read-only, I > have never, ever, seen any database application that did not need > transactions. Ever. > > There's more to transactions than just grouping together multiple SQL > statements. > > If you do any INSERTs, UPDATEs, or DELETEs at all, you need > transactions, even if there are no indexes involved, even if the > individual statements don't affect each other. > > Even a simple insert can involve multiple operations like requesting > more disk space from the OS, rearranging pointers in the database file > on the disk, etc. > > What happens if there's a power failure while it's in the middle of that > insert? With transactions, it gets rolled back when things start up > again. Without, you could wind up with a corrupted database. You are mixing two different issues: atomic operations and automatic repair after crash. MyISAM tables *are* atomic. Even if you update 1000 rows at once, another process will never see a moment when only 500 of them are updated and another 500 are not. About repair, yes, MySQL is not as much concerned about that, and it never became a problem to me either (my servers don't crash every day :)). See, if your server died in the middle of transaction, the best thing even a transactional DBMS can do it to roll it back. *But you will lose that data anyway*, despite that the table would be "not corrupted", and usually, data loss is more serious issue rather than a need to run table check for several seconds. MyISAM tables would never become so popular if automatic rollback after crash was a serious issue for server owners. Regards, Serge _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
