2 vbulletin dbs bridge?

[k007]

is there a script/hack out there that bridges two vbulletin databases? i dont want to merge them, i just want to be able to use both of them at the same time.

[Dismounted]

There may well be, but none that I know of.

[Adrian Schneider]

I've created one but the complexity of it is nearly overkill for just synchronizing users.

A simple option (passed my basic proof of concept test) would be using MySQL's new view functionality instead. Absolutely backup first.

For every shared table (user, usergroup, userfield, access, etc.) you would need to drop the original table, and then recreate it as a view:

CREATE VIEW user as
SELECT * FROM source_db.user;MySQL properly optimizes away the view since it's a simple view.

So, automatically, when vBulletin performs queries on any of these "view" tables, MySQL will simply replace the database/table names so it directly touches the other database.

Pros
Easy to maintain
Should be very fastCons
Limited to same physical server
More risk (6 sites dependent on one)
Not stress tested -- Possible complications... ?

[Dismounted]

So basically a symbolic link to another database? That's cool, when was it introduced into MySQL, Adrian? I'm afraid I don't really keep up with MySQL :p.

[Adrian Schneider]

Not really new... but new enough for most people not to have it. 5.01, according to the docs (http://dev.mysql.com/doc/refman/5.0/en/views.html).

This isn't really what they were meant for, but hey it works. :up:

[Wilfred1]

I've created one but the complexity of it is nearly overkill for just synchronizing users.

A simple option (passed my basic proof of concept test) would be using MySQL's new view functionality instead. Absolutely backup first.

For every shared table (user, usergroup, userfield, access, etc.) you would need to drop the original table, and then recreate it as a view:

CREATE VIEW user as
SELECT * FROM source_db.user;MySQL properly optimizes away the view since it's a simple view.

So, automatically, when vBulletin performs queries on any of these "view" tables, MySQL will simply replace the database/table names so it directly touches the other database.

Pros
Easy to maintain
Should be very fastCons
Limited to same physical server
More risk (6 sites dependent on one)
Not stress tested -- Possible complications... ?
I know this is a bit old but how did the views option go?

I would very much like to test this so any idea what the source_db syntax would be for the user table located in a separate db on the same server?

[Adrian Schneider]

I've only tested it in a development environment... never on a production site.

"source_db" is the name of the other database that you want to pull the users from.

[Wilfred1]

Thanks Sir Adrian but wouldn't need some form of connection string not just the name but username and password as well?

[Dismounted]

No, the database user that you access the DB with just needs to have permissions to the other DB.