|
Roberto C. Sánchez
roberto at connexer.com
Wed Mar 28 07:36:29 EST 2007
On Wed, Mar 28, 2007 at 12:02:14PM +0200, Mike Looijmans wrote: > This thread is going way of topic, but I'd really hate to see people being > turned away from MySQL as a DB engine just because of the inaccuracies > posted here. > I always welcome a good exchange :-) > I have several years of experience with many DBMSs, including Informix, > Oracle, MS SQLServer, Postgress, MySQL and several others. MySQL is my > favorite for (non-.NET) web applications, because of its scalability, > performance, reliability, low maintenance and ease of use. > > There are many DBMSs, each with their own pecularities, and none of them I > would consider "bad" (or even "evil"). Which DBMS to chose for a particular > task seems to become a matter of personal taste more everyday, because the > more general offerings, like the ones I mentioned, all provide the same > rich feature set (e.g. transactions, subqueries, stored procedures, outer > joins). While I would not hesitate to recommend in favor of some of the > databases I am familiar with, there is not one that i would ever tell > people to "avoid at all cost". Even FoxPro has its uses. > I am only familiar with MySQL and PostgreSQL, so I cannot speak to the others. However, in MySQL if you have multiple tables involved in a transactional query and even *just one* was created as non-transactional, your *entire* transaction is no longer a transaction, and MySQL doesn't give an error. I consider that to be slightly more than a "peculiarity." > >Sorry, but accepting invalid input without error, truncating overly long > >input and clipping overflowed numbers are not "quirks". > > I agree so far. > > > They are serious data integrity issues. > > I disagree here, because the issues you mentioned are configuration > settings in MySQL. You can change the behaviour of the server in the config > file. It is unfortunate that the default settings are not the ANSI ones. > But you can make the MySQL DB comply to the more general standard of > issuing an error on overflow and other forms of invalid input. > I'm sorry, but this just bogus. Here are some things to consider: * "hose my data" should *never* be a valid configuration * many people fear changing the defaults since it breaks applications that are designed to work or tested only against the defaults > I suggest reading some documentation before proceeding on the subject. > I have. For many years, the MySQL documentation presented nonsense arguments against transactions and why they were bad. Then, in a recent version they finally introduced real transactional support and those arguments went away, as in simply disappeared, from the documentation. There are other examples, but that one alone has (at least in my eyes) damaged the credibility of the MySQL developers quite badly. > >That's fine. At least you aren't really using MySQL in production :-) > > I have. On my previous assignment, the customer would loose about $10k per > hour in lost machine time only (not even taking the engineers cost into > account) if the MySQL database went offline. It did go offline once in that > three year period i worked there - the power went down, the UPS failed and > the operating system (Solaris) died a horrible dead along with the hard > drive. When the power came up, I had its replacement up and running in > about ten minutes, and no data was lost. > That sort of thing should be par for the course for *any* database. Saying that MySQL can recover well from even a hardware problem (except maybe for a complete hard disk failure) should be nothing special. I understand that MySQL is useful. I understand that it has its place. However, I still maintain that it should not be the first thing recommended to newbies (as it often is). The reason is that its "peculiarities" are actually often serious issues which newbies often will not understand (if they are even aware of them in the first place). If an expert (such as yourself) decides to use MySQL it is with full knowledge of the situation which you are entering (that is, that you must modify a host of configuration settings in order to get MySQL to act more like a proper database). Someone who is unaware of those issues is likely to not understand why when he inserts an invalid date or a number that is too large for its column his database ends up with invalid or just plain wrong data. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070328/89262f53/attachment-0001.bin
|