The purpose of this patch is to provide for a database abstraction structure within WordPress while causing minimal disruption to the WordPress core and without losing core WP features. To accomplish this we have provided for SQL dialect translations, which is not the best way to achieve database abstraction, but what we feel is best given the WordPress environment. It should be noted that WordPress plans on moving to PHP 5 only, and because of this we are also providing for a couple of PDO drivers. There are translations currently for SQL Server and Sql Azure databases, however the patch is structured so that other database translations could be provided for, such as PostgreSQL or SQLite.
Another reason for our decision to provide database abstraction with a dialect translation layer is that we do not want to disturb the optimizations done for MySQL queries. You can use this patched version of WordPress with MySQL and it will run just like it does for normal WordPress. This seems to be a big issue with the WordPress community, as they don’t want to lose optimized queries for MySQL in exchange for more generic queries that are usually associated with database abstraction.
Of course, database abstraction could be provided for while keeping optimized queries for the respective database, but this would require a large overhaul to the WP code base. To do this, WordPress would need adopt a proper Model layer, in which there would be functions mapping to the data manipulation/retrieval needed. For example, instead of having calls to $wpdb->insert(‘SQL’) throughout the code base,those calls would be replaced by calls to specific Model functions such as $wpdb->newPost($new_post_info). This DB_MySQL::newPost() function could be optimized for MySQL whereas DB_SqlSrv::newPost() could be optimized for SQL Server. Both DB_MySQL and DB_SqlSrv would extends a base DB class and the instance you would be working with would be determined by the database you are connecting to. Using this Adapter pattern with PDO is something we feel would be ideal. While it would mean a lot of work,Wordpress would be able to appeal to many more potential users with different environments.
Many ask why this wasn’t done as a WordPress plugin. There are several reasons. One reason is that to achieve proper database abstraction as a plugin makes for some difficulty and quirks. We also feel that database abstraction as a plugin would cause more headache and difficulties long term and that database abstraction should be a part of WordPress core.
While we are discussing plugins, it should be noted that these translations were done for core WP functionality, which means that there may be plenty of plugins out there making MySQL specific queries that we may not be translating correctly. This would result in the plugin not working properly, or at all. If WP did implement database abstraction, this of course would be something that would need good answers. For example, perhaps we could mark all existing plugins as MySQL compatible and then encourage the plugin developers to update their plugins for compatibility with other other DBs, if it isn’t already, and be able to mark it as such. WordPress installations connecting to a non-MySQL database would be able to sort/search by those that are compatible with their DB, or which are untested. Many of the popular plugins we tested worked with our translations without any need for changes.