4 ms·

You're creating the wrong impression here by calling MySQL a toy and citing a handful of user preference issues you have with arcane features. http://www.mysql

You're creating the wrong impression here by calling MySQL a toy and citing a handful of user preference issues you have with arcane features. http://www.mysql.com/customers/ http://www.mysql.com/customers/ MySQL is used by the largest and most successful companies in the world. It is incredibly performant and stable in the most brutal environments. Who on earth expects transactions to be available when you're creating a schema? "drop table if exists" is a fine way to back-out if your deployment dies. Deferred key constraints? You should be spanked for using those in the first place.

gfodor 16y ago
This is a weak argument. Deferred key constraints and the other intra-transactional feature mentioned are hardly bad practice, since you're relying upon the database to cover your ass. Go figure, that's what a database is supposed to do. You should be free to do anything in a transaction you wish, it is, after all, not committed until you say so. The appeal to authority doesn't add any weight to the argument.
kls 16y ago
MySQL is used by the largest and most successful companies in the world. It is incredibly performant and stable in the most brutal environments. I hate that line, you know what most of these companies have in common? They where started by guys with only a few years in the field and a vision. Some of them not the best developers in the world, just guys with a great idea for a product and a passion. The other thing they have in common, is that they have spent millions if not more on rolling their own solutions to compensate for a technology decision they made a long time ago in a garage. This is the way it works, the new guys come in, they say well company X uses this, they build something on it because X is using it and they hit growing pains at a certain point. Twitter is experiencing those growing pains now, fortunately they seem to be throwing out the bad and trying new things. A good deal of companies become dogmatic about their choice and given their success just throw money at it to build compensating workarounds. MySQL was not chosen by those companies because of its merits, it was chosen because those companies started in a garage, and the technical selection was "what are the other guys using in their garage".
- alexsolo 16y ago
  Or just because MySQL is really to get started with when using Rails and other frameworks, and that when you're starting a business, you think "if I actually ever run into MySQL scaling issues, that's a good problem to have".
  - blueberry 16y ago
    Name one database that won't have scaling issues for sure. Scaling DB-wise is not only a good problem, it is inevitable if you constantly grow.
    - mmt 16y ago
      Name one database that won't have scaling issues for sure You are, in effect, asking someone to prove a negative. I don't think there's any contention that scaling will always be an issue, but, rather, where along the scale curve debilitating issues occur and how painful the resolutions to those issues are. For example, with MySQL, without sacrificing ACID properties[1], one cannot even separate a table's indexes onto a separate spindle from its data. For rotating storage, this make creating a new index astonishingly painful. Even with SSDs, more sequential/bulk I/O combined with eliminating contention for the paths to the drive, there can be a performance improvement. Then there's query optimization. Is there even anything remotely close in MySQL to the EXPLAIN ANALYZE functionality in PostgreSQL? I posit that scaling issues with MySQL come early and, once they do, require sweeping and expensive changes to address. One can't merely exercise a little cleverness and cheap hardware to tide one over for another factor of 2-4 growth. [1] i.e. InnoDB, not MyISAM
- llaxsll 16y ago
  It's an ok environment. There is a lot of tooling around it which is to its advantage. Once you start doing something more advanced, though, you start seeing its flaws. I've had pretty miserable time with its query optimizer and sprocs.

gfodor 16y ago

This is a weak argument. Deferred key constraints and the other intra-transactional feature mentioned are hardly bad practice, since you're relying upon the database to cover your ass. Go figure, that's what a database is supposed to do. You should be free to do anything in a transaction you wish, it is, after all, not committed until you say so. The appeal to authority doesn't add any weight to the argument.

kls 16y ago

MySQL is used by the largest and most successful companies in the world. It is incredibly performant and stable in the most brutal environments. I hate that line, you know what most of these companies have in common? They where started by guys with only a few years in the field and a vision. Some of them not the best developers in the world, just guys with a great idea for a product and a passion. The other thing they have in common, is that they have spent millions if not more on rolling their own solutions to compensate for a technology decision they made a long time ago in a garage. This is the way it works, the new guys come in, they say well company X uses this, they build something on it because X is using it and they hit growing pains at a certain point. Twitter is experiencing those growing pains now, fortunately they seem to be throwing out the bad and trying new things. A good deal of companies become dogmatic about their choice and given their success just throw money at it to build compensating workarounds. MySQL was not chosen by those companies because of its merits, it was chosen because those companies started in a garage, and the technical selection was "what are the other guys using in their garage".

alexsolo 16y ago
Or just because MySQL is really to get started with when using Rails and other frameworks, and that when you're starting a business, you think "if I actually ever run into MySQL scaling issues, that's a good problem to have".
- blueberry 16y ago
  Name one database that won't have scaling issues for sure. Scaling DB-wise is not only a good problem, it is inevitable if you constantly grow.
  - mmt 16y ago
    Name one database that won't have scaling issues for sure You are, in effect, asking someone to prove a negative. I don't think there's any contention that scaling will always be an issue, but, rather, where along the scale curve debilitating issues occur and how painful the resolutions to those issues are. For example, with MySQL, without sacrificing ACID properties[1], one cannot even separate a table's indexes onto a separate spindle from its data. For rotating storage, this make creating a new index astonishingly painful. Even with SSDs, more sequential/bulk I/O combined with eliminating contention for the paths to the drive, there can be a performance improvement. Then there's query optimization. Is there even anything remotely close in MySQL to the EXPLAIN ANALYZE functionality in PostgreSQL? I posit that scaling issues with MySQL come early and, once they do, require sweeping and expensive changes to address. One can't merely exercise a little cleverness and cheap hardware to tide one over for another factor of 2-4 growth. [1] i.e. InnoDB, not MyISAM
llaxsll 16y ago
It's an ok environment. There is a lot of tooling around it which is to its advantage. Once you start doing something more advanced, though, you start seeing its flaws. I've had pretty miserable time with its query optimizer and sprocs.