Switching the vBulletin user database

[Ecksta C]

Hi all,

I'm currently looking at a couple of discussion boards on behalf of my company. Basically we're looking to add discussion boards functionality to our existing websites.

I've recommended VB because i've used it a fair bit on my personal sites before.

I've always based my user database on the vb_user table - sensible for a site which doesn't have any users to begin with.

However, my company has several thousand users already stored in a database, off which multiple sites run, so changing the database that users' details are stored in to VB is out of the question (all of the other sites would have to have their SQL rewritten).

What I really want to do is have VB use our 'One Database' for authentication and also perform password updates and other specified profile fields on it.

The obvious problem is that VB has hardcoded SQL statements that reference the vb_user table...

Has anybody ever been in the same situation? I haven't thought it through a great deal yet as I'm hoping somebody else has already gone this process.

Any theories/ideas are appreciated!

[w1z4rd]

What platform are the sites you are referencing? Alot of CMS' and blog platforms already have solutions that integrate with vbulletin to varying degrees. Other then that you would probably have to get a vb guru to write a script that could sync the desired tables of your databases.

I don't really know what I'm talking about though so I'd definitely seek alternate answers. Just trying to be helpful.

[Ecksta C]

The platform is completely custom and has been written in-house so there's no integration with vBulletin.

The only thing that I've come up with so far is very similar to what you've said here... writing a script that has the ability to syncronize data from our custom DB with the vBulletin one when an update occurs and vice versa.

Another potential solution that I was thinking about was creating a view from our custom database and calling it vb_user instead of the table shipped with vBulletin. This would allow us to keep the vBulletin code the same and change the datasource at the database level rather than when PHP runs.

The only problem is that when it comes to updating or inserting to that view, we'll run into problems because you can't insert/update a row with a column that is derived from an expression (see this from the MySQL manual on views).

A view that has a mix of simple column references and derived columns is not insertable, but it can be updatable if you update only those columns that are not derived. Consider this view:

CREATE VIEW v AS SELECT col1, 1 AS col2 FROM t;

This view is not insertable because col2 is derived from an expression. But it is updatable if the update does not try to update col2. This update is allowable:

UPDATE v SET col1 = 0;

This update is not allowable because it attempts to update a derived column:

UPDATE v SET col2 = 0;

So... any ideas how I could get around this perhaps? It seems to be the least intrusive to me...