4 ms·

MySQL is richly deserving of ridicule as well. It's ubiquity is unfortunate.

jbooth 13y ago
If you're going to comment so strongly, some explanation of why it deserves such ridicule would contribute much more value to the discussion.
- twic 13y ago
  No check constraints. Spotty transaction isolation. Silent data corruption if you happen to make certain kinds of updates while using statement-based replication. No on-line schema updates (is that still true?). Complete inability to execute joins of any size in reasonable time due to the lack of merge or hash join strategies. Corresponding inability to handle subqueries of any complexity. Readers block writers (at table level with MyISAM - and still at row level with InnoDB?). As well as things like that which are actually ridiculous, there is also the substantial gap in features as compared to real databases. Things like recursive queries, user-defined types, partial indices, etc, are commonplace in the more sophisticated databases. You probably won't need them for a simple web application (or even a complex one!), but they can be very useful when trying to do more complex things, or manage a complex system efficiently.
  - asperous 13y ago
    Besides the corruption, that just sounds like it's missing features. Missing features is ridicule worthy?
    - regularfry 13y ago
      It can be when you look at how long people have been asking for these things.
    - twic 13y ago
      When the "feature" is a basic property of a relational database - as check constraints and efficient joins and subqueries are - then yes.
  - AlisdairO 13y ago
    I believe that InnoDB is an MVCC implementation, so readers blocking writes shouldn't happen. Another thing to add to your list is missing window functions. I'm not a big MySQL fan at all, but it's still leaps and bounds ahead of mongo technologically.
    - yxhuvud 13y ago
      Readers blocking writes may have been changed in a never version than what we use, but it still exist in at least some versions of 5.x.
      - AlisdairO 13y ago
        My apologies - you're right. In the general case readers don't block writes, but InnoDB does use share locks on some foreign key interactions and when using the SERIALIZABLE isolation level.
    - mdellabitta 13y ago
      Just ran into this link, which seems to describe how MVCC can sometimes not be enough. http://ronaldbradford.com/blog/understanding-innodb-mvcc-2009-07-15/ http://ronaldbradford.com/blog/understanding-innodb-mvcc-200...
      - AlisdairO 13y ago
        Having read through it, I rather suspect that that's not a matter of writers blocking readers or the other way round, but instead a case of writers blocking writers - he's writing a lot of data to the table, and it's highly likely that InnoDB has escalated the lock to a table lock - which effectively prevents concurrent writes.
        twic 13y ago
        I don't believe that InnoDB escalates locks. Quoting from the fine manual: http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-model.html http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-mo... > InnoDB does locking on the row level and runs queries as nonlocking consistent reads by default, in the style of Oracle. The lock information in InnoDB is stored so space-efficiently that lock escalation is not needed: Typically, several users are permitted to lock every row in InnoDB tables, or any random subset of the rows, without causing InnoDB memory exhaustion.

If you're going to comment so strongly, some explanation of why it deserves such ridicule would contribute much more value to the discussion.

twic 13y ago
No check constraints. Spotty transaction isolation. Silent data corruption if you happen to make certain kinds of updates while using statement-based replication. No on-line schema updates (is that still true?). Complete inability to execute joins of any size in reasonable time due to the lack of merge or hash join strategies. Corresponding inability to handle subqueries of any complexity. Readers block writers (at table level with MyISAM - and still at row level with InnoDB?). As well as things like that which are actually ridiculous, there is also the substantial gap in features as compared to real databases. Things like recursive queries, user-defined types, partial indices, etc, are commonplace in the more sophisticated databases. You probably won't need them for a simple web application (or even a complex one!), but they can be very useful when trying to do more complex things, or manage a complex system efficiently.
- asperous 13y ago
  Besides the corruption, that just sounds like it's missing features. Missing features is ridicule worthy?
  - regularfry 13y ago
    It can be when you look at how long people have been asking for these things.
  - twic 13y ago
    When the "feature" is a basic property of a relational database - as check constraints and efficient joins and subqueries are - then yes.
- AlisdairO 13y ago
  I believe that InnoDB is an MVCC implementation, so readers blocking writes shouldn't happen. Another thing to add to your list is missing window functions. I'm not a big MySQL fan at all, but it's still leaps and bounds ahead of mongo technologically.
  - yxhuvud 13y ago
    Readers blocking writes may have been changed in a never version than what we use, but it still exist in at least some versions of 5.x.
    - AlisdairO 13y ago
      My apologies - you're right. In the general case readers don't block writes, but InnoDB does use share locks on some foreign key interactions and when using the SERIALIZABLE isolation level.
  - mdellabitta 13y ago
    Just ran into this link, which seems to describe how MVCC can sometimes not be enough. http://ronaldbradford.com/blog/understanding-innodb-mvcc-2009-07-15/ http://ronaldbradford.com/blog/understanding-innodb-mvcc-200...
    - AlisdairO 13y ago
      Having read through it, I rather suspect that that's not a matter of writers blocking readers or the other way round, but instead a case of writers blocking writers - he's writing a lot of data to the table, and it's highly likely that InnoDB has escalated the lock to a table lock - which effectively prevents concurrent writes.
      - twic 13y ago
        I don't believe that InnoDB escalates locks. Quoting from the fine manual: http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-model.html http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-mo... > InnoDB does locking on the row level and runs queries as nonlocking consistent reads by default, in the style of Oracle. The lock information in InnoDB is stored so space-efficiently that lock escalation is not needed: Typically, several users are permitted to lock every row in InnoDB tables, or any random subset of the rows, without causing InnoDB memory exhaustion.