It does not matter if they used PDO or mysql_ calls directly - that could be fixed with a search'n'replace. The real problem is the SQL that's executed - to rewrite that you need to understand what it does etc. And if you're going to switch to a different database, you're doing it to use unique features it provides, which often means you need to rewrite parts of the SQL.
And how does that contradict the fact that MySQL gains some speed advantage due to lack of some features? Yes, the situation improved recently - the InnoDB fixed some of the MyISAM problems (altough the system catalogs are still MyISAM).
You're mixing MyISAM and InnoDB storage engines. REPEATABLE READ is the default level for InnoDB, but most RDBMS default to READ COMMITED isolation level (e.g. Oracle, PostgreSQL). With MyISAM this does not make much sense, it's similar to READ UNCOMMITED. And it's not true MySQL does not enforce foreign keys - you've mentioned REPEATABLE READ so you've been talking about InnoDB, and that engine does enforce foreign keys.
Separating all the data access into a DAO layer might make the switch easier, although it may be a significant amount of code and it may even require a rewrite of some parts of the application. Anyway IoC has nothing to do with it - IoC is mostly about instantiation and lifecycle management, not about proper layering.
I wonder what you find "horrible" on the PostgreSQL security model. It's not perfect (what is?), but I find it comparable to other databases I work with. I've never considered it a roadblock, especially compared to quirks in the security models of other databases. Plus the config is very flexible and easy (have you ever tried to use Kerberos with MySQL?).
Yes, the replication stuff may seem a bit rough, and you're right it's not a complete HA solution. But it's not that difficult to prepare a shell script that does that last step (switching to a slave database when the master fails). But it's a matter of preference - I've been working with other databases and I really appreciate this flexibility over a very limited GUI tool. And there are tools that might work for most users (e.g. repmgr).
Differential backups - yes, that's one feature I'm missing. Although you can archive transaction logs, and you can do filesystem snapshots and combine that.
Funny. The "Safe Browsing" Firefox addon (operated by Google), marks this page as 'dangerous' e.g. phishing / malware. A page talking about Google stealing IP from other PayPal, marked as phishing by Google - I really wonder how that could happen.
No, not really. The currencies are strong when the government / FED can't play with them and do crazy things like 'quantitative enrichment' etc. One way to achieve this is to bind the currency to some rare thing - it may be gold, in this case it's bitcoins.
The "value" is a bit abstract term, but it just means that two parties agree to use something (papers printed with a green ink, bitcoins, pieces of gold,...) to pay for real goods and services. The scarcity does not create the value, but it makes sure none of the parties can create it on their own. Although in some cases it's clear one of the parties can do that and even be proud of it - e.g. FED is printing sh**loads of money, but when you try to do the same there will be suits with guns knocking on your door.
Slashdot Mirror
It does not matter if they used PDO or mysql_ calls directly - that could be fixed with a search'n'replace. The real problem is the SQL that's executed - to rewrite that you need to understand what it does etc. And if you're going to switch to a different database, you're doing it to use unique features it provides, which often means you need to rewrite parts of the SQL.
And how does that contradict the fact that MySQL gains some speed advantage due to lack of some features? Yes, the situation improved recently - the InnoDB fixed some of the MyISAM problems (altough the system catalogs are still MyISAM).
You're mixing MyISAM and InnoDB storage engines. REPEATABLE READ is the default level for InnoDB, but most RDBMS default to READ COMMITED isolation level (e.g. Oracle, PostgreSQL). With MyISAM this does not make much sense, it's similar to READ UNCOMMITED. And it's not true MySQL does not enforce foreign keys - you've mentioned REPEATABLE READ so you've been talking about InnoDB, and that engine does enforce foreign keys.
Separating all the data access into a DAO layer might make the switch easier, although it may be a significant amount of code and it may even require a rewrite of some parts of the application. Anyway IoC has nothing to do with it - IoC is mostly about instantiation and lifecycle management, not about proper layering.
I wonder what you find "horrible" on the PostgreSQL security model. It's not perfect (what is?), but I find it comparable to other databases I work with. I've never considered it a roadblock, especially compared to quirks in the security models of other databases. Plus the config is very flexible and easy (have you ever tried to use Kerberos with MySQL?). Yes, the replication stuff may seem a bit rough, and you're right it's not a complete HA solution. But it's not that difficult to prepare a shell script that does that last step (switching to a slave database when the master fails). But it's a matter of preference - I've been working with other databases and I really appreciate this flexibility over a very limited GUI tool. And there are tools that might work for most users (e.g. repmgr). Differential backups - yes, that's one feature I'm missing. Although you can archive transaction logs, and you can do filesystem snapshots and combine that.
Funny. The "Safe Browsing" Firefox addon (operated by Google), marks this page as 'dangerous' e.g. phishing / malware. A page talking about Google stealing IP from other PayPal, marked as phishing by Google - I really wonder how that could happen.
No, not really. The currencies are strong when the government / FED can't play with them and do crazy things like 'quantitative enrichment' etc. One way to achieve this is to bind the currency to some rare thing - it may be gold, in this case it's bitcoins. The "value" is a bit abstract term, but it just means that two parties agree to use something (papers printed with a green ink, bitcoins, pieces of gold, ...) to pay for real goods and services. The scarcity does not create the value, but it makes sure none of the parties can create it on their own. Although in some cases it's clear one of the parties can do that and even be proud of it - e.g. FED is printing sh**loads of money, but when you try to do the same there will be suits with guns knocking on your door.
It usually works for me ...