MySQL is less of a joke than MongoDB is. They similarly started by someone who didn't know anything about databases and learned about them on the go. Actually both of them started as much faster alternatives to other databases, both ended up having complete rewrite of its engine written by someone from outside that knew their stuff. MySQL ISAM then MyISAM and then InnoDB (written by an outsider). Similarly MongoDB got a WiredTiger written.
The thing is that MySQL is older so it went through all of it earlier, but it still suffers from poor decisions from the past. This is contrasting with PostgreSQL, where correctness and reliability was #1 from the beginning. It started as an awfully slow database, but performance for improved and we now have correct, reliable and fast database.
If you were around back in the day you will remember the MySQL team claiming that no one needed transactions or referential integrity, that you should just do it yourself in the application...
MySQL's rise IMO cannot be considered without also looking at the rise of Ruby on Rails and other CRUD-optimized platforms and frameworks. Also ORMs. These things denigrated the idea of using an RDBMS as anything but a dumb table store. Features like stored procedures and views were seen as pointless. MySQL was the perfect database for people who had no respect for databases.
I agree that the rise of MySQL is combined with using RDBMS as a table store rather than a relational database, but I am not positive that this was driven by RoR and ORMs. Every large-scale system I have worked with that utilizes MySQL (and I'm on at least my third in a row of these systems, sadly!) is/was driven by application-logic database utilization via the "FriendFeed model" - that is, a big fat ID->Document Blob table for persistence and breakout tables for indexing.
ORMs and ActiveRecord in particular encourage, to some extent, the use of a RDBMS, even if they didn't get to take advantage of them well for a long time - for example, in RoR "has_one / has_many" for foreign-key relationship, .joins(:field_name) for, well, joins, and so on.
Perhaps. Something happened between those first-generation web sites where you were writing SQL by hand -- so you could just as easily be writing (injection-attack-prone) queries that made use of stored procedures etc -- and today.
A big reason I called out RoR is that back in '04-05 I was railing against its default use of plural table names, and DHH on IRC recommended I shut up and just flip the configuration switch and turn off the feature, but of course when I did that all sorts of latent bugs were exposed.
RoR was the beginning of hipster "coding" and I therefore blame it for everything.
I'm wasn't previously familiar with the FriendFeed approach to database (ab)use. I paid about as much attention to it as I did to MySpace back in the day -- nearly zilch -- so its etc innards are doubly obscure to me.
MySQL was already ridiculously popular from use in PHP/MySQL applications well before Rails was popular. That said, I generally agree with your statement:
> MySQL was the perfect database for people who had no respect for databases.
No, but it does support online DDL for some operations in InnoDB.
Very few database systems support online DDL, which unlike a transaction, does not require undo or rollback resources.
Of course one must have a rollback procedure if something fails, but you need one for transactions too, just in case.
An online rollback is far lest costly than a transactional rollback, because and online rollback is just undoing what you did. Added a column you didn't want in one query? Remove it again in another, very quickly.
TokuDB (a mysql/mariadb storage engine) supported all DDL as an online operation. But percona killed it in favour of TokuMX, the MongoDB equivalent.
TokuMX has no upgrade path to wired tiger, only one major customer at Percona (I can't say who it is) and no engineers.
Any kind of DDL is tricky and requires users to RTFM for the intricacies of their chosen database. One size rarely fits all.
TokuDB is a great storage engine! Online DDL and fast compression are a winning combo. We use it for all our big MySQL tables. It is still available in MySQL 8.0.
I really wish Percona would reconsider their decision to deprecate it.
After Percona took over TokuDB's creator TokuTek, they wasted so much of their development time and money on TokuMX (Percona's fractal tree-enabled MongoDB server) only to abandon it in 2017.
That money would have been better spent on TokuDB development to allow it to match the features present in InnoDB like generated columns, spatial indexing, fulltext Indexes and Galera.
TokuDB still has many users and MyRocks is just no substitute.
The thing is that MySQL is older so it went through all of it earlier, but it still suffers from poor decisions from the past. This is contrasting with PostgreSQL, where correctness and reliability was #1 from the beginning. It started as an awfully slow database, but performance for improved and we now have correct, reliable and fast database.