3 ms·

It is powering the core function of the sites i.e. it is the primary databases in all cases. I am sorry but are you that deluded as to think so many of the wor

It is powering the core function of the sites i.e. it is the primary databases in all cases. I am sorry but are you that deluded as to think so many of the world's leading IT companies are going to choose a database that silently loses data ? Do you really think they are that stupid ? I mean come on.

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 ago
  It'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.
einhverfr 14y ago
Are you sure? Do we have evidence that the accounting end of the advertisement network, etc. is handled on MySQL? Or is it the backend for the public side only? Let me give you an example. I have a customer that uses MySQL for some processing on their web site and all data gets batched up nightly and entered into the PostgreSQL-based accounting system. The MySQL db is accessed only by the app which does the processing and the connectors to the PostgreSQL db. The PostgreSQL db has a lot more logic in it and is a lot more complex. In their case, their environment is not subject to any of the MySQL gotchas. They can make sure the credit card processing software runs in an acceptable SQL mode, and if something goes wrong between the PostgreSQL export of reports and the MySQL public side (which has happened for reasons other than MySQL's fault), they can track down and fix the problem. That's what loosely coupled systems are about. IT in this case is about risk management. How can you guarantee that specific important data will not be lost. You can do this with MySQL for some set of environments (either because the data truncation isn't a big deal, regarding your tweets, or because it can be retrieved from another source, or because there is only one app accessing the database so you don't have to worry about apps turning off strict mode), but you can do it with PostgreSQL for a much larger set of environments and that's what the complaint is.

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 ago
It'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.

einhverfr 14y ago

Are you sure? Do we have evidence that the accounting end of the advertisement network, etc. is handled on MySQL? Or is it the backend for the public side only? Let me give you an example. I have a customer that uses MySQL for some processing on their web site and all data gets batched up nightly and entered into the PostgreSQL-based accounting system. The MySQL db is accessed only by the app which does the processing and the connectors to the PostgreSQL db. The PostgreSQL db has a lot more logic in it and is a lot more complex. In their case, their environment is not subject to any of the MySQL gotchas. They can make sure the credit card processing software runs in an acceptable SQL mode, and if something goes wrong between the PostgreSQL export of reports and the MySQL public side (which has happened for reasons other than MySQL's fault), they can track down and fix the problem. That's what loosely coupled systems are about. IT in this case is about risk management. How can you guarantee that specific important data will not be lost. You can do this with MySQL for some set of environments (either because the data truncation isn't a big deal, regarding your tweets, or because it can be retrieved from another source, or because there is only one app accessing the database so you don't have to worry about apps turning off strict mode), but you can do it with PostgreSQL for a much larger set of environments and that's what the complaint is.