Unfortunately thats only a year ago. I believe MySQL added transactions over a decade ago and you still run into people who insist MySQL doesn't have transactions, because five years ago they read something written seven years ago that was years out of date at that time.
You just don't see behavior like that outside the database community. Hey did you know that BIND doesn't support IPv6? Yeah version 4.9.3 doesn't support ipv6. Don't bother me with facts like version 9.0 was released more than thirteen years ago in 2000.
So once every installed and reasonably security patched mysql server in the world supports hash joins, the world has at minimum a decade of people who have no idea what a hash join is, and no idea how or why to use it, none the less demanding that mysql doesn't support it.
(Bitter? Yeah maybe a little. You can get good advice about OS, or compilers, off the internet. But overall the internet is useless for database advice, a couple stars don't outshine the greater cesspool)
I have long said: "MySQL is the PHP of databases."
In my experience, the database is capable, but the database itself has some quirks (whether these are due to the database itself or the developers I do not know). Some things I do know for sure:
- I worked on a product which supported MsSQL, Oracle, Postgres, and MySQL. Only MySQL compared character columns in a case insensitive way which caused us some extra work, but we did fix this using the proper collation.
- I worked on a Django project. When using MySQL, a Django ORM query would pull the entire result set and hold it in memory while you iterated over it, sometimes consuming gigs of ram if we weren't careful. Iterating over a result set from Postgres would pull (presumably) only one result at a time. Whatever the case, it didn't cause memory problems like MySQL. This is not MySQL's fault, but again, it was the exceptionally problematic database.
- I'm currently working with a MySQL database which is quite troublesome because foreign-keys are not enforced. See a non-null foreign-key? You might expect it to refer to an existing record, but you'd be wrong. Again, failure of the developers, not the database.
- I also am currently working with a MsSQL database. We had to add a column to a MsSQL table; no locking, no problem. Then I had to add a column to a MySQL table, which locked the entire table for the length of the operation. MySQL was, again, problematic where another database was not.
There are other problems I have only heard of, but I will not mention those. All the above are personal experiences where MySQL was causing trouble where other databases were not. It parallels my experience with PHP, both are great tools if used right, but they seem to be misused more often then other technologies.
"MySQL database which is quite troublesome because foreign-keys are not enforced"
Not sure what this means. Innodb will enforce them and has been the default for "awhile" although if you don't configure FKs it won't automagically do it for you (superficially, a DBMS that assumed any column named user_id is a FK for table user column id, although I bet that would create some amazing bugs occasionally) If you use myisam you can hack in FKs using triggers, which is icky/foul but you only have to do it once in the design phase. Or just don't use myisam unless you need its sometimes somewhat higher speed.
Something I say a lot is its a philosophical outlook difference. Outta the box, MySQL is a cub scout who always does his best, which may or may not have anything to do with what you think is a reasonable goal. On the other hand outta the box some DB like Postgres have no sense of humor and will go on strike / curl up and die if you ask it do something somewhat imperfectly or without the proper precise etiquette. Its somewhat easy to spend some time configuring either toward your project's philosophy or your personal philosophy.
This philosophy thing is why your comparisons were insensitive... the default outta the box collation was (is?) something weird like latin1_swedish_ci and if you merely change it to latin1_general_cs or whatever it "just works" and becomes case sensitive. Well what does the helpful cub scout mysql do, it makes sure you get all the results you could possibly want, in addition to some you probably don't.
I have run into slow schema mod problem before. Solution, don't change your schema.
MySQL has been my go-to database for years because it was fast, reliable and effective. Unfortunately it hasn't been evolving as quickly as other databases, Postgres in particular.
There's a lot of quirks in MySQL that were excusable a decade a go, but now they're problems that've been solved in virtually every other database engine. Working with Sybase was never a pleasant experience, but versions a decade old have features that MySQL still doesn't have.
Every so often you'll hit the wall with MySQL, little things like applying a LIMIT in a subselect, or row length limitations, that will make you wonder why you're using MySQL at all.
Actually that's what I thought, but it's not always the case. Sometimes a good chunk of the TEXT type column is saved in the row itself (~768 characters), and when the length exceeds that, the remainder is stored in the blob area of the table store. (http://www.mysqlperformanceblog.com/2011/04/07/innodb-row-si...)
This depends on your row format, an obscure technical issue most never have to deal with, but it can be a problem.
I agree, and it's unfortunate, but you also see this happen in the programming language community as well, just look at the wealth of perpetuated ignorance around PHP for instance.
Fair enough, don't ask the internet for advice on databases, language selection, and how about editor. Maybe not as unique as I initially claimed but the situation still sucks.
The upthread comparison was to PostgreSQL (which fully supports transactional DDL), not Oracle (which does not.)
(Oracle 11g R2 provides something like Transactional DDL via Edition Based Redefinition. MS SQL has partial support for transactional DDL; PostgreSQL, DB2, Firebird, Informix, and Sybase Adaptive Server all support Transactional DDL [1].)
A conspiracy theory would be putting an intentionally buggy one in their free offering. It would have to be buggy by design such that it would be incompatible with a later patch. Then put non buggy design 2.0 in the paid product. Perhaps the inability to design a bad design like that is why that scenario hasn't been initiated. Sometimes it is hard to think of intentionally bad code, although it seems easy enough to generate when I'm trying to write good code.
They're doing all kinds of awesome and the greater community is starting to see this, which is evident with Archlinux* for example whom has dropped MySQL in favour of MariaDB.
Slowly but surely MySQL will fall to the waysides, which I can't help but think is what Oracle wants.
even if you kill 80% of free signups to MySQL to get 10% of those converted to premium offerings, it would be worth it.. the rest would go to other MySQL-compatible drop-in replacement solutions, like MariaDB
