11 ms·

I really don't know where to begin with such a stupid comment. How about you start with listing which of these companies needs educating: http://www.mysql.com/

I really don't know where to begin with such a stupid comment. How about you start with listing which of these companies needs educating: http://www.mysql.com/customers/ http://www.mysql.com/customers/ Facebook ? Twitter ? Amazon ? Flickr ?

jacques_chester 14y ago
In some of these cases MySQL is not being used as an RDBMS. And in most of those cases it looks like path dependency rather than a selection based on the merits of this or that database. Either way, this is actually an argument from authority ("So and so use Brand X, therefore Brand X has positive qualities Y"). I've sat in on presentations with DB2 engineers who bragged about the data centre IBM runs for UPS. ~12 billion transactions per day (and that was 5 years ago). Does UPS make DB2 better or worse than MySQL? Answer: it's irrelevant. DB2 and MySQL would need to be picked on their merits, not their users.
- LaGrange 14y ago
  It does invalidate claims that using product X is going to inevitably cause you huge problems once you "grow enough". I've seen a lot of places grow a lot while using MySQL, and the problems aren't really that different or more serious than in places using Postgres or Oracle. In fact, I know enough places moving from Postgres to MySQL due to growing pains.
  - jacques_chester 14y ago
    Right, but we're not talking here about scale. We're talking about ... trustworthiness, I suppose. Dependability. What this article demonstrated is that MySQL will often give a false sense of security. That's not what you want from a system ostensibly meant to provide a number of important technical guarantees. Multi-master is the one tickbox feature where MySQL is still clearly in front. Once the PostgreSQL team finish going about inbuilt multi-master in their usual meticulous, stepwise fashion (my WAG is that it'll land by 9.6), there really won't be any good technical reasons left to use MySQL.
    - LaGrange 14y ago
      But I didn't mean "grow" in exclusively performance meaning. I meant the whole package (as with growth the requirements for reliability also ultimately show up, at least in some parts of the business). Even my current job that involves a lot of MySQL has important chunks of Must Never Go Away Or Else data, with a lot of complex insert/update action going on them, and somehow it's working fairly well for us.
      - jacques_chester 14y ago
        One of the persistent themes of the linked piece is that MySQL simply conceals many kinds of fault. "Somehow it's working fairly well for us" may be right. Or it might not. Either way, MySQL isn't going to warn you.
        LaGrange 14y ago
        With default settings. I agree that keeping them as default is fairly bad, but in a growing scenario you need people who know the defaults very well anyway. After all, quiet database silliness is only one of the many ways you can quietly corrupt huge swaths of data. It's similar to Rails – the defaults save your time, and in their case are arguably reasonable, but if you don't know how and why they work, they are going to bite you. There is no escaping from knowing about the complexity, but you may escape from typing it out every single time.
        jacques_chester 14y ago
        This is a mechanism vs policy argument. Defaults count. Elsewhere I've said that I prefer to start with rigid guarantees and relax them. Default policy matters because in practice: * The documentation isn't read. * Even when it's read, the documentation may be incomplete. * When it's read and complete, the crucial segment may be skimmed. * When the documentation is complete and the crucial segment was read, it may have been misunderstood because of unclear writing. * When the documentation is complete and the crucial segment was clearly written and read, it may be forgotten later on. Then a new DBA or programmer arrives, and the whole thing starts all over again. Safety mechanisms that require active effort above the baseline configuration do not work very well. Saying "there is a great mechanism" does not describe the actual properties of the actual system. The default policy is the policy that counts, because a single omission will reintroduce it. Windows XP, buffer overflows, botched system deployments and so on all have a common property: they require positive effort by humans in order to rise above their baseline safety/security/reliability profile. There is no failsafe -- they only work by constant vigilance. I don't see that as a good thing.
justinjlynn 14y ago
The analogy goes like this: If you're very rich, you can do horrible drugs and pay a veritable army of people to keep you presentable and working. Of course, this until one day it doesn't. Being large and successful doesn't mean that there's nothing festering deep within. Companies and people can become so invested in previous solutions that the perceived benefit versus the cost of switching is almost always too low to gather enough political will to execute. MySQL is a drug, when you start it is cheap and available, but as you grow as you hope you will, you start to need more and more. Of course, this exposes many of the flaws and problems of the drugs you were on and if you're in a bad way, still are. Better to go through a bit of pain now and know what you're in for than to just use MySQL because facebook, twitter, amazon, and flickr can pay a huge team of people or large consulting firms to make their technology decisions actually work. If you really must, use MySQL to spike the product but know the side-effects and know when to get the hell off it.
twerquie 14y ago
He's clearly talking about people new to databases who choose MySQL because of its ubiquity, not seasoned engineers and large companies operating legacy applications. > Facebook ? Twitter ? Amazon ? Flickr ? I imagine none of these companies would choose MySQL if starting from scratch today.

jacques_chester 14y ago

In some of these cases MySQL is not being used as an RDBMS. And in most of those cases it looks like path dependency rather than a selection based on the merits of this or that database. Either way, this is actually an argument from authority ("So and so use Brand X, therefore Brand X has positive qualities Y"). I've sat in on presentations with DB2 engineers who bragged about the data centre IBM runs for UPS. ~12 billion transactions per day (and that was 5 years ago). Does UPS make DB2 better or worse than MySQL? Answer: it's irrelevant. DB2 and MySQL would need to be picked on their merits, not their users.

LaGrange 14y ago
It does invalidate claims that using product X is going to inevitably cause you huge problems once you "grow enough". I've seen a lot of places grow a lot while using MySQL, and the problems aren't really that different or more serious than in places using Postgres or Oracle. In fact, I know enough places moving from Postgres to MySQL due to growing pains.
- jacques_chester 14y ago
  Right, but we're not talking here about scale. We're talking about ... trustworthiness, I suppose. Dependability. What this article demonstrated is that MySQL will often give a false sense of security. That's not what you want from a system ostensibly meant to provide a number of important technical guarantees. Multi-master is the one tickbox feature where MySQL is still clearly in front. Once the PostgreSQL team finish going about inbuilt multi-master in their usual meticulous, stepwise fashion (my WAG is that it'll land by 9.6), there really won't be any good technical reasons left to use MySQL.
  - LaGrange 14y ago
    But I didn't mean "grow" in exclusively performance meaning. I meant the whole package (as with growth the requirements for reliability also ultimately show up, at least in some parts of the business). Even my current job that involves a lot of MySQL has important chunks of Must Never Go Away Or Else data, with a lot of complex insert/update action going on them, and somehow it's working fairly well for us.
    - jacques_chester 14y ago
      One of the persistent themes of the linked piece is that MySQL simply conceals many kinds of fault. "Somehow it's working fairly well for us" may be right. Or it might not. Either way, MySQL isn't going to warn you.
      - LaGrange 14y ago
        With default settings. I agree that keeping them as default is fairly bad, but in a growing scenario you need people who know the defaults very well anyway. After all, quiet database silliness is only one of the many ways you can quietly corrupt huge swaths of data. It's similar to Rails – the defaults save your time, and in their case are arguably reasonable, but if you don't know how and why they work, they are going to bite you. There is no escaping from knowing about the complexity, but you may escape from typing it out every single time.
        jacques_chester 14y ago
        This is a mechanism vs policy argument. Defaults count. Elsewhere I've said that I prefer to start with rigid guarantees and relax them. Default policy matters because in practice: * The documentation isn't read. * Even when it's read, the documentation may be incomplete. * When it's read and complete, the crucial segment may be skimmed. * When the documentation is complete and the crucial segment was read, it may have been misunderstood because of unclear writing. * When the documentation is complete and the crucial segment was clearly written and read, it may be forgotten later on. Then a new DBA or programmer arrives, and the whole thing starts all over again. Safety mechanisms that require active effort above the baseline configuration do not work very well. Saying "there is a great mechanism" does not describe the actual properties of the actual system. The default policy is the policy that counts, because a single omission will reintroduce it. Windows XP, buffer overflows, botched system deployments and so on all have a common property: they require positive effort by humans in order to rise above their baseline safety/security/reliability profile. There is no failsafe -- they only work by constant vigilance. I don't see that as a good thing.

justinjlynn 14y ago

The analogy goes like this: If you're very rich, you can do horrible drugs and pay a veritable army of people to keep you presentable and working. Of course, this until one day it doesn't. Being large and successful doesn't mean that there's nothing festering deep within. Companies and people can become so invested in previous solutions that the perceived benefit versus the cost of switching is almost always too low to gather enough political will to execute. MySQL is a drug, when you start it is cheap and available, but as you grow as you hope you will, you start to need more and more. Of course, this exposes many of the flaws and problems of the drugs you were on and if you're in a bad way, still are. Better to go through a bit of pain now and know what you're in for than to just use MySQL because facebook, twitter, amazon, and flickr can pay a huge team of people or large consulting firms to make their technology decisions actually work. If you really must, use MySQL to spike the product but know the side-effects and know when to get the hell off it.

twerquie 14y ago

He's clearly talking about people new to databases who choose MySQL because of its ubiquity, not seasoned engineers and large companies operating legacy applications. > Facebook ? Twitter ? Amazon ? Flickr ? I imagine none of these companies would choose MySQL if starting from scratch today.