3 ms·
http://en.wikipedia.org/wiki/MyISAM http://en.wikipedia.org/wiki/MyISAM > MyISAM was the default storage engine for the MySQL relational database management sy
by wisty 14y ago
http://en.wikipedia.org/wiki/MyISAM http://en.wikipedia.org/wiki/MyISAM
> MyISAM was the default storage engine for the MySQL relational database management system versions prior to 5.5
This is what the anti-MySQL crowd is talking about - the dark days when MySQL lacked transactions, referential integrity, and concurrency. It was basically the SQLite of its day.
There's nothing wrong with all that if you just want a key-value store, which is what most web apps are.
And it generally doesn't "silently lose data" unless you are touching that data. It tends to just silently do stuff that doesn't quite make sense. Like if you post in a thread, and your "post count" goes up but your post itself fails, it's not a huge problem. Unlike in an accounting app, where you really don't want a transaction to partially work (e.g. money falling through the cracks).
When MySQL broke on a website, I think most people just assumed it was internet gremlins.
- einhverfr 14y agoIt's not just MyISAM though. The fact is that these things actually make sense when you think about MySQL as being a content-management backend for the web. The problem actually has to do with SQL modes, the fact that MySQL will silently substitute table backends for you, and much more. Again in some environments this is ok, and if you have total control and tight control over a small number (preferably only 1) of applications hitting your db it isn't the end of the world. But PostgreSQL folks look at MySQL from a different perspective. It's a db-centric rather than app-centric perspective. In this perspective your db needs to guarantee that declarative constraints will be followed. In this perspective the db is the center of the environment, not the bottom tier of the app stack. In this perspective you could potentially have dozens of apps using a single db. It isn't a matter of MySQL having grown up a bit (and it has). It is a matter of it not having outgrown the content management and/or single app per db environment in which it arose.