If you're going with MySQL, it's also worth taking a look at MariaDB and Percona Server. They're both drop-in replacement forks of MySQL with an emphasis on performance, plus they both have additional features that are pretty handy.
Jarin On Saturday, November 22, 2014 9:34:15 PM UTC-8, Ian Young wrote: > > 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] <javascript:>> > 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] <javascript:> > 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] <javascript:>. > 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.
