On Saturday 10 Nov 2001 21:00, Franklin Schmidt wrote: > The worst thing any development tool can do is silent unwanted favors. > Java and C don't do unwanted favors which is why they are great. > Javascript and most Microsoft tools do lots of unwanted favors which is > why I hate them. This is a personal preference but I suspect most > programmers with experience in large projects share this preference. > MySQL does many unwanted favors to avoid rollback. This was a bad > design decision because update speed usually doesn't matter much. What > matters is the speed of reading and reliability of the data.
That is very arguable. IMHO, the design decision was the correct one because the primary design goal of MySQL is speed. There are lots of databases out there. Use the one that agrees with you. If you want referential integrity checks, triggers, detailed data checking, defaults, stored procedures, etc, you should probably be using a different database. Personally, I use PostgreSQL a lot of the time, when I need the features listed above. When the primary requirement of my application is speed, I use MySQL, because it is AT LEAST twice as fast as PostgreSQL on most things, sometimes much faster. You cannot have it all. Now, can we please stop the criticism thread, and stick to doing the sensible things, i.e. using the right tool for the job? > My point about unique indexes is that I assume that this forces MySQL to > deal with the rollback problem anyway. Any reduction in the frequency of the rollback problem is beneficial if performance is the primary requirement. > If you have a multi-row insert > and one of these rows violates a unique index, what does MySQL do? Besides, uniqueness checking on an index for the insert is likely a lot faster, as typically it only needs checking on one of two fields per table, as opposed to EVERY field in the table. There is also less data transferred and overheads than doing a SELECT first to see if there's a records already there. > You > either do a rollback or lose atomicity. This looks like exactly the > same problem that you would have implementing NO DEFAULT or any other > column value sanity check in the database. But it unarguably reduces the frequency of the problem, and thus the speed of operation in most cases. Just MHO... Regards. Gordan --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
