On Jun 3, 2011, at 6:16 PM, Darren Duncan wrote: > Mr. Puneet Kishor wrote: >> On Jun 3, 2011, at 1:19 PM, Darren Duncan wrote: >>> MySQL should be avoided like the plague. >> why? >> This is a long standing (un)conventional wisdom to which I too have hewed. >> Now, it so happens, I will be starting work on a project that uses MySQL >> exclusively, and has done so for years. They have been very happy with it. >> And, even though I feel like telling them that they should move to Pg, I >> don't really know what the reasons are. I am not sure if all the reasons that >> might be, are still valid. >> Of course, I don't want this to become a long, religious threat that might be >> inappropriate for this list, or bore most of the other readers to tears. But, >> it merits asking, why should MySQL be avoided like the plague? It is a strong >> statement that requires backing evidence, else it would be construed FUD. > > Perhaps my statement was a bit strong, so I will clarify a bit. >
You don't say. "Should be avoided like the plague" is way more than a bit, hence, my response. > *And* I'll give concrete examples. > > 1. Firstly, the context for my statement is someone who is not currently > using MySQL, and so they don't already have an investment in it and codebase > designed for it. > > If one is already using MySQL, then that is the status quo and the question > is on whether benefits from a change to something else is worth the effort or > not. But if one is not already using it, and their current DBMS can't be > used how they need, then they have to change anyway and the question is > between whether to move to MySQL or to something else instead; I am > addressing this latter situation, and you'll notice I also said sticking with > SQLite is even better if its usage can be fixed. The same could be said of anything... "if its usage can be fixed" is a clause that can be interpreted widely. > > 2. I consider MySQL to be an 80% solution. > > It does the job for which it is used adequately in many cases, and it is > successfully used in many places, including to drive many businesses and > organizations for mission-critical purposes. > If "it is does the job for which it is used adequately" then it is a 100% solution. > .. > > a. MySQL silently ignores all CHECK constraints in all engines, so for > example you can't even tell it you want a column to only hold values between > 1 and 10. > Its in the MySQL docs: "The CHECK clause is parsed but ignored by all > storage engines." Yes and no. Apparently the above was true before 5.0.2, but apparently it has been fixed since then. From the docs, "Before MySQL 5.0.2, MySQL is forgiving of illegal or improper data values and coerces them to legal values for data entry. In MySQL 5.0.2 and up, that remains the default behavior, but you can change the server SQL mode to select more traditional treatment of bad values such that the server rejects them and aborts the statement in which they occur." and "In MySQL 5.0.2 and up, you can select stricter treatment of input values by using the STRICT_TRANS_TABLES or STRICT_ALL_TABLES SQL modes: SET sql_mode = 'STRICT_TRANS_TABLES'; SET sql_mode = 'STRICT_ALL_TABLES'; > > b. That's just an example of how MySQL silently ignores lots of errors or > silently changes data on you, such as silently truncating text values that > are too long for a field when you insert them, so you've lost data without > even knowing it. (Okay, I knew about this one previously.) Shown by another poster to not be true. No point in going through all the issues you pointed out. I am sure some of them are true, while others no longer true, or true but have work-arounds. > .. > > I say avoid MySQL like the plague because it will bite you in so many ways, > while an alternative like Postgres will only bite you in relatively few and > less painful ways. Postgres is more of a 90-95% solution relative to MySQL's > 80%, assuming that there is no 100% solution. > > I also know quite a number of savvy people in the developer communities who > have used both Postgres and MySQL, and a vast majority of those prefer > Postgres and strongly recommend it over MySQL when one has a choice, and so > do I. > The main thing is to be aware of as much as possible, and then figure out work-arounds. No technology is perfect. There could be serious, project-specific show-stoppers that would cause one to choose a particular tech over another, but those would be project-specific. I have no love for MySQL. All I want to emphasize is that statements like "avoid it like the plague" become sound-bytes with no substance. They are hollow and misleading as "Having problems? Get a Mac" or, on the other side, "Don't use Macs for serious work" or "Perl is dead" or "Apple is dead" and the like. These statements are fine for bloggers and tech journalists to make for their aim is to get page-hits and their opinions are usually worthless anyway. All that said, I too would personally choose SQLite and then Pg, in that order, if I had a say. But, that is not relevant here. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
