Why Should You Use MySQL?
jeremymorgan.com
jeremymorgan.com
What a crappy defense.
There is little I like about MySQL but here's a few reasons I still recommend people use it:
1. It's already part of something delivering value to your business. E.g. Nagios, MediaWiki or some other LAMP stack solution you've deployed. It's there. You're using it. Learn to live with it, and be sure to BACK IT UP!
2. You need to work with data someone gave you that came from a MySQL system. E.g. a Wikipedia dump. Someone else already lived the pain of collecting data into MySQL, now all you need to do is refine it.
3. You're publishing data for someone else to load into their MySQL system (e.g. a Pentaho warehouse).
MySQL is in production and we have to live with it. The defences in the linked article are all valid. MySQL is a very sharp tool and can be used effectively. But its time has passed. Start your new projects on a more solid footing.
Because what you fail to understand is that people aren't switching from SQL to SQL they are switching to NoSQL and doing so en masse. Have you not seen the huge array of NoSQL options that weren't available 15 years ago e.g. MongoDB, CouchBase, Riak, Cassandra, HBase, Redis. And the upcoming trend is going to be in Graph databases e.g. Neo4J.
My prediction is that every SQL and NoSQL system you mention will evolve towards being producers and consumers of SQL and NoSQL interfaces. I.e. like SQLite4 over KV, or Oracle memcache over InnoDB.
1) Your legacy shared hosting site might provide MySQL and not Postgres.
There are also 9 reasons to choose one of {Postgres, MySQL} over {Oracle, SQL Server}.
Here is 1 reason to use Postgres: data integrity.
"00/00/0000 00:00:00.0000" is not a real date, but MySQL will helpfully insert it into your table if you try to insert NULL into a non-null datetime field. (One example among many.)
SET sql_mode = 'STRICT_ALL_TABLES';
Yes, it's not default. Yes, it can be overridden. Yes, that bothers a lot of people.
With good reason. This is your database we're talking about. If it's going to be sloppy with your data by default, it's the wrong tool.
"it's the wrong tool" is an opinion and it is unsupported by history. It many cases, it's exactly the right tool and users are given the power to control the level of strictness they they require. Want to allow GROUP BYs that don't include all non-aggregate columns? Sure, you can do that. Or not. Want MySQL to accept what you give it and throw warnings instead of errors? Yep, you can do that, too. Or not.
The defaults are bad. No one will defend that. They are also easy to change. A privilege level allowing/denying the ability to change the sql_mode would be a welcome addition, also. Yet, MySQL is a capable tool that does some things really well, something things not so well, and some things terribly. Just like every other product out there. It is a tool. It works well for many, but not all cases. Apparently, you find it inadequate for your particular needs. I get that. You shouldn't use it.
As for the "No True Scotsman" notion, fair enough; point conceded. I just can't imagine anyone who actually, you know, cares about their data being happy about finding out — by virtue of the fact that the sloppy behaviors are the default — that they've lost data, or had it corrupted somehow, because of those defaults.
Yes, it's their responsibility, in choosing the tool, to make sure they're using it properly. But the folks making the tool should also have some degree of responsibility to their users not to fuck up their data. Maybe I'm just spoiled, having lived and worked in the PostgreSQL world as long as I have. There, breaking users' data is tolerated about as well as Linus tolerates kernels breaking userspace...
3) Decent monitoring.
4) Commercial support.
And your argument about data integrity is valid but in the real world moot. Most developers are using an ORM these days which abstract problems like these away.
EnterpriseDB, Command Prompt, 2nd Quadrant, and all the others listed under http://www.postgresql.org/support/professional_support/
Many of those companies have people on staff who are members of the PostgreSQL core committee, or at least have commit bits. Can MySQL say the same?
If your response is going to be "But that's not commercial support from 'PostgreSQL' itself", that's the nature of the community. It was a deliberate choice by the community to structure itself that way: PostgreSQL — the community, the brand, or whatever you want to call it — can't be sold. This is a good thing, and I don't think I need to waste much time explaining why...
The only reason to go with mysql is when one uses a CMS that is tied to mysql ( wordpress for instance or several ecommerce scripts).
Otherwise there is no need to stick to MYSQL.
There is a reason why I, as someone whose experience in principally in data management, does not "write applications" - I might be able to write something that works, but it will likely lack security, stability, scalability. The same things happen with app developers, without an equivalent of database expertise, will make similar mistakes.
You may need a team of "certified" DBAs, but you need someone to guide the development of a stable foundation.
One thing I like about MySQL is the support available from third parties like Percona - I'll also recommend the book "High Performance MySQL", which gives some great details on performance tuning and query optimizing.
I'm not familiar with the offers for PostgreSQL - I'd like to hear what support services and books people with PostgreSQL experience would recommend.
http://www.postgresql.org/support/professional_support/
For books, among the most important is Greg Smith's "PostgreSQL 9.0 High Peformance", but really, just search Amazon for "PostgreSQL" and browse the titles until you find one that matches your needs.
Personally, I've been working with postgres for a decade now. Most of what I've needed, I've just gotten from searching a/o asking on the mailing lists.
Another thing that is often overlooked is tiered slaves in conjunction with logical replication for adding OLAP to an OLTP infrastructure. This allows you to have additional reporting data on slaves that is not present on the master and along with real-time replication, eliminating or simplifying nightly batch processing. This also allows you to keep a very small working set available on the master database with slaves that contain the full archive. In conjunction with BLACKHOLE tables, this can be very powerful.
Ironically, Oracle also is connected to Java.
That makes absolutely no sense what so ever. Java is the dominate enterprise development platform.
MySQL is most popular in non-enteprise environments.
Java is a technology (including web plugins) that has received a lot of criticism from the community. Just recently the Department of Homeland Security had to chime in and recommend that users disable Java due to security concerns. MySQL has always received criticism due to various issues.