leadZERO
Fri 2nd Aug '02, 11:52am
From looking at the source code it looks like the developers originally intended to abstract the database from the program; and they half did. They wrapped almost all of the database calls, which is a good thing. However, most of the queries are still highly connected with MySQL.
I fear we are already too far down the road in development to have making the program database independent be a simple task. Infact, I imagine it would require a substantial amount of time to completely separate the program from the back-end. Optimally when a new forum is created the admin should be able to just use a drop-in replacement and use the database of his choice (that has a drop-in written of course). Most people probably would not use this since they are already setup with MySQL. However, down the road some forums, including this one, might benefit from using another database engine for speed. Or a site might already be using a certain database engine and not want to have to worry about maintaining two separate databases for users. If they were able to just drop-in a back-end replacement (say a few files) they would have the ability to integrate vBulletin with their existing database without having to do a complete rewrite every time a new version of vB is released.
MySQL is pretty fast as far as databases are concerned, but it doesn't support most of the standard SQL features almost every other SQL engine supports. MySQL 4 is supposed to help bring MySQL closer to a feature set comparable to that of other SQL databases. However, vBulletin is so attached to MySQL 3 making use of these new features in MySQL 4 will be a large task for the development team. And that is why I suggest before we wait any longer we take the steps necessary to make vB3 database independent.
It’s probably too late to consider doing this for the 3.0 release. However, once vB3 starts entering the RC phase it might be wise to have a few people work on this. Luckily it’s the kind of thing that doesn’t have to be completed immediately; both the old non-abstracted and the new abstracted code can coexist as long as MySQL 3 is used. This could be a nice addition to a major revision (vb3.1).
I, personally, am happy with MySQL since all of my servers are UNIX based. However, some of the windows users might like being able to use an enterprise MSSQL server instead. I would however like to use the new additions to MySQL when 4.0 goes into beta. However, as vBulletin stands making use of those new features would be a big job.
Anyone interested in what they have planned for MySQL 4 should check out http://www.mysql.com/products/mysql-4.0/index.html
Some of the highlights include: online hot backup and replication services, ability to change mysqld parameters without taking the server down, FULL TEXT searches to make use of FULLTEXT indicies, full transaction and row-level locking in InnoDB tables, secure links between client and server and many others. MySQL4.1 is slated to include: nested subqueries, stored procedures and multi-table UPDATEs.
I fear we are already too far down the road in development to have making the program database independent be a simple task. Infact, I imagine it would require a substantial amount of time to completely separate the program from the back-end. Optimally when a new forum is created the admin should be able to just use a drop-in replacement and use the database of his choice (that has a drop-in written of course). Most people probably would not use this since they are already setup with MySQL. However, down the road some forums, including this one, might benefit from using another database engine for speed. Or a site might already be using a certain database engine and not want to have to worry about maintaining two separate databases for users. If they were able to just drop-in a back-end replacement (say a few files) they would have the ability to integrate vBulletin with their existing database without having to do a complete rewrite every time a new version of vB is released.
MySQL is pretty fast as far as databases are concerned, but it doesn't support most of the standard SQL features almost every other SQL engine supports. MySQL 4 is supposed to help bring MySQL closer to a feature set comparable to that of other SQL databases. However, vBulletin is so attached to MySQL 3 making use of these new features in MySQL 4 will be a large task for the development team. And that is why I suggest before we wait any longer we take the steps necessary to make vB3 database independent.
It’s probably too late to consider doing this for the 3.0 release. However, once vB3 starts entering the RC phase it might be wise to have a few people work on this. Luckily it’s the kind of thing that doesn’t have to be completed immediately; both the old non-abstracted and the new abstracted code can coexist as long as MySQL 3 is used. This could be a nice addition to a major revision (vb3.1).
I, personally, am happy with MySQL since all of my servers are UNIX based. However, some of the windows users might like being able to use an enterprise MSSQL server instead. I would however like to use the new additions to MySQL when 4.0 goes into beta. However, as vBulletin stands making use of those new features would be a big job.
Anyone interested in what they have planned for MySQL 4 should check out http://www.mysql.com/products/mysql-4.0/index.html
Some of the highlights include: online hot backup and replication services, ability to change mysqld parameters without taking the server down, FULL TEXT searches to make use of FULLTEXT indicies, full transaction and row-level locking in InnoDB tables, secure links between client and server and many others. MySQL4.1 is slated to include: nested subqueries, stored procedures and multi-table UPDATEs.