[mangel.ajo]

Originally Posted by tfw2005

So, if you have 4 forums active, with members and posts now, you would first need to merge the databases manually, making sure each have their own prefix in the new mega DB. Then, somehow import just users from the other 3 into the primary one, and merge accounts for duplicate users. Then install the script, and use primary site user tables from there forward. That sound right?

Hmmm, that's the most complex situation, joining forums that are already running.

First of all, you would have to merge all the users in the Primary forum database, and then -somehow- manage to change all your userid's from pms, posts, threads, and so one to the new ID of the joined database. I'm not sure but that could require specific scripts.
[/quote]

Second, how is performance affected? I have several 1 million+ post forums, probably 100,000 members between them. After combining it all, the DB would be 4-6 gigs. Those are some large table scans. When server load is heavy now, I get issues with a 1.5 gig DB being accessed repeatedly (getting new server, but still).

It should add len(shared_tables)*4 str_replaces to every SQL query your system is doing. Probably is not too much, but it's load, of course. (We could do some tests to discover how much is that.)

We should also think if mysql would also penalyze us by having all the tables in one database with same prefix.

So, yes, I know you need a solid server just to handle a large DB situation in general, but, how much overhead does this script use, and could it "crap out" if dealing with large amounts of data like this. Several 1000+ users online sites accessing the same DB concurrently.

We will have to analyze that. May be running some test over real vbulletin querys and measuring time.

Disk based avatars and profile pics need to be addressed, as anyone with a lot of members most likely moved to that. Xcache, memcached, eaccelerator issues need to be tested for sure. I couldn't use that until it was in some way.

I've been thinking more deeply about memcached / xcache an so on, and probaby it won't be a problem, but we must test.

Question - I take it this does not "log you in" to another site, on another domain, it just makes your user account available to log in again if you go there, correct? So you are logged in and viewing site A, then jump to site B, you would need to log into site B then again. Site A and B are different domains. Correct?

Yes, exactly, that's it. Don't know if it would be possible to develop some kind of mechanism to move around forums using the different session tables to move around forums.

RE: Mysql view, I looked into that, and many people online say that it is not designed for high volume usage, and could actually slow things down. Tho, I just quickly scanned, and don't have deep knowledge of it in general. I'd like to hear how the view technique would work in the above situation too.

I've never tested it, and for the simplest idea (having the mirror of a diferent table it should'nt be so slow. But analyzing VIEW in depth you can see it let's you make some complex views selecting some rows in tables, and that its a complex situation, and being prepared for that could be the reason of slowliness.

And, for the record, I would love VB to have something built into the backend for this officially, more integrated and optimized. Would allow for some really cool stuff.

Absolutely: me too.