On Thu, Mar 19, 2009 at 3:23 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:
Right . There will be situations where MySQL with MyISAM will be a good fit. My point was more that it doesn't make sense to simply compare "speed" becuase other things needs to be taken into account.
On Thu, Mar 19, 2009 at 3:26 PM, John Cheng <chonger.cheng@xxxxxxxxx> wrote:Sure, if the application fit. If I have to load 100Meg files into a
> Comparison between MySQL using the MyISAM engine with PostgreSQL is really
> not sensible. For one, the MyISAM engine does not have transaction and
> foreign key support, while PostgreSQL supports transaction and foreign key.
> Would anyone really give up transaction and integrity for slightly more
> performance?
db, run some simple extraction on them, and output it back out, and
can recreate all my data at the drop of a hat, then mysql / myisam
might be a good match.
Right . There will be situations where MySQL with MyISAM will be a good fit. My point was more that it doesn't make sense to simply compare "speed" becuase other things needs to be taken into account.
I am no a fan of MySQL, more because the company behind it seems to be
lost and drifting than the db itself. Bugs that are 5 years old
finally getting fixed after Monty chided them in december? Come on,
PostgreSQL comes out with a near bug free new version every 1 to 2
years. PostgreSQL stomps bugs in hours or days that MySQL AB takes
YEARS to fix, and then get reintroduced (see the order by on innodb
indexed field debacle for that story) and I just don't trust the
company or the db for anything complex. But as a tool it has some
uses that it's good enough at I could use it if I had to.
--
- John L Cheng
