Re (tilly) 7: DBI and table locking

Have you never noticed that a relational database that has locking is a way to manage locks across processes that are on several different machines and possibly operating systems?

*grin*

And AFAIK (*), what MySQL current calls transactions doesn't pass the ACID test. I tend to not like it when people use words that already have perfectly good meanings to mean something else...

* I may be wrong on this. As you can tell, I don't use MySQL.

Comment on Re (tilly) 7: DBI and table locking

Replies are listed 'Best First'.
Re: Re (tilly) 7: DBI and table locking by salvadors (Pilgrim) on Jan 08, 2001 at 00:27 UTC
I haven't really been following any of the discussion on BDB MySQL, but as far I can see, the only part of the ACID test that it fails now is Consistency. MySQL itself doesn't enforce any kind of integrity constraints, preferring to leave this up to the application. Whether or not this is actually a necessary condition of 'transactionness' is debatable IMO. Tony	[reply]
Re: Re: Re (tilly) 7: DBI and table locking by Jonathan (Curate) on Jan 08, 2001 at 19:16 UTC
I agree with tilly. This all boils down to use. For a lot of web based sites MySQL works fine. It's free and unlike a major RDBMS doesn't require a DBA life support team (ie boring people like me :-). However, for a full blown application with multiple concurrent users with a complicated Database design, MySQL cannot be considered as a serious choice. Aside from whats been mentioned above, such as the lack of Database procs, It doesn't scale so well and the fundamental SQL is restricted for example Update statements cannot have a from clause (ANSI SQL'92 compliant but functionally very restrictive).	[reply]
Re: Re: Re: Re (tilly) 7: DBI and table locking by salvadors (Pilgrim) on Jan 08, 2001 at 21:53 UTC
MySQL ... doesn't scale so well We're getting WAY off topic here, but I don't think that is at all true. I'm not sure what you mean by scale - concurrent users / queries / whatever, but we're currently putting over 2000+ queries per second through a 500+ tables MySQL set-up - and that's a mix of INSERT/UPDATE/SELECTs - not just SELECTs.... The trick is to not write SELECTs that take a long time to run (measured in hundredths of seconds!) on tables that also need updated or inserted into. Taking a schema which works on Oracle or whatever, and trying to port it to MySQL will fail. Designing to MySQLs strengths and using them to build a large system is however very possible. To bring this back on topic slightly, I treat statements like "you can't build a full-blown application with MySQL" just as I treat "you can't build a full-blown application with Perl"... Tony	[reply]