Chris, I think there's a kernel of truth in what you're saying. Guyren points out a whole bunch of extra stuff that Postgres adds to the SQL experience, and if you want that bonus material it's clearly superior. For most of us, most projects, most of the time, there's no need to step outside the bounds of standard SQL, and in that scenario, MySQL and Postgres have more in common than they do apart. Both are stable & mature & well-supported, both won't lose your data through any fault of their own, both are fast enough that you're limited much more by disk read speed and the quality of your indexes than by the database itself.
Even in these situations, MySQL does have some distinct flaws. It has some poor engineering decisions in its history that follow it around, and many of the default settings on a MySQL install are things that you won't notice at first and then will regret deeply later on. The ones I can think of off the top of my head: * It uses MyISAM as the default storage engine (though apparently in newer versions this has changed). MyISAM is a shitty storage engine that uses a dumb file format and lacks some important features like transactions. There's a much better InnoDB storage engine available, but if you don't know to switch to that out of the gate, migrating after the fact is a huge pain. * There are something like 5 different places to set the string encoding (i.e. Latin1 vs UTF8). These settings apply at different points in the pipeline, are very hard to track down and understand, and worse, they can be set in conflicting ways and will proceed to interact with each other in mind-boggling ways. Oh, and last I checked MySQL defaults to Latin1, which is something that you never ever want when starting a green-field DB in this day and age. * It does some terrible and bizarre things with type casting values (the details escape me at the moment). * Table names are case-insensitive on Windows & OSX, and case-sensitive on Linux. Arrrrrrrrrrgh. All these things *can* be mitigated, and if you're careful in how you configure and use MySQL, it's not going to sink your company. So if you have a compelling reason *to* use MySQL, I say go for it. But if you lack a strong argument for MySQL, why invite all these problems into your project for no reason? I suggest you consider Postgres the default choice, and require a convincing reason to make an exception for MySQL (or any other DB option). Ian On Fri, Nov 21, 2014, at 06:47 PM, Chris Schulte wrote: > Guyren, > > Do you have a similar link explaining why Postgres is superior to > MySQL? I know Postgres has all the momentum now in the developer > community, but I can't seem to find any extremely compelling reason > why it's held in such high regard over MySQL (other than the whole > evil corporate Oracle owns MySQL thing). > > Most of the research I've done comes to the conclusion that they're > basically the same, so if you have 10+ years of experience with one > then just stick with it. But that doesn't explain why every developer > I meet turns his/her nose up at the mere suggestion of using MySQL. > > So if you've got some good links I'd appreciate it if you could pass > them along and convince me otherwise. I just haven't heard any reason > yet that's convinced me to make the switch. > > -- > Chris > > > On Friday, November 21, 2014, Guyren Howe <[email protected]> wrote: >> I’ve not worked with it nearly as much as MySQL or Postgres. But >> seems I can now be almost as harsh about MS SQL Server as I have been >> about MySQL: >> >> <http://www.pg-versus-ms.com/> >> >> That just leaves Oracle. I *have* worked a goodly amount with Oracle. >> Oracle is significantly better than SQL Server and MySQL. And I can >> even imagine situations where I would choose Oracle over Postgres. >> Were I to describe such a situation, I would begin with something >> like “well, I suppose if I was working for a bank…”. >> >> For everyone else, Postgres is clearly, I will even say outrageously, >> obviously, and dramatically, the best database available today. >> >> On related news, I’m currently working on some tests of Postgres’ >> special indexes for the next meeting. The GIN index has just received >> a dramatic improvement in Postgres 9.4 (both smaller and faster). I’m >> planning on presenting results giving an indication about when you >> might want to use GIN or GIST indexes. For those who saw my last >> presentation about indexes, compound GIN and GIST indexes let the >> database use any of the columns in the index for a search. They are >> rather more complex than BTree for the database to maintain, so this >> involves a tradeoff between insert and query time that ought to be >> explored in more depth. >> >> I’m planning on running some benchmarks that will give us at least a >> rough idea of how GIN and GIST indexes compare for insert and query >> time against BTree indexes. If you use Postgres, you should come hear >> what I find out. >> >> >> >> >> >> -- >> -- >> SD Ruby mailing list [email protected] >> http://groups.google.com/group/sdruby >> --- >> You received this message because you are subscribed to the Google >> Groups "SD Ruby" group. To unsubscribe from this group and stop >> receiving emails from it, send an email to >> [email protected]. For more options, visit >> https://groups.google.com/d/optout. > > -- > -- > SD Ruby mailing list [email protected] > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google > Groups "SD Ruby" group. To unsubscribe from this group and stop > receiving emails from it, send an email to > [email protected]. For more options, visit > https://groups.google.com/d/optout. -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
