Syncing Databases like Profiles?

Profile tables on 2 different databases...

After learning a bit more about syncing databases and understanding the overwhelming multiplie options between two sites and further multiples of, is it not possible to sync the profiles database to allow pass throughs for not only access but data also if synced!  It also appears to me without a doubt that this configuration would also allow for lets make this easy:

1st joined site the end user has multiple features they can use based on whatever configuration I decide to allow. 1st site being sub-domain.

2nd synced site the end user now has access but an entirely different set of possibilities tied to the 2nd site being main domain.  

Is it me or is a dressed down subdomain with 0 crons but the platforms perform remarkably better than a main domain burdened with mutiple crons?  

The 50,000 member question is on a deticated server which is better to desiminate total traffic with the above variables of one main domain vs one domain with an additional sub-domain.  

Obviously there are tremendous amounts of variables like the use of the RMS server both using the same.  

How in the name of higher math and probability does anyone ever calculate the needs of the server(s) based on the unknown probability of what a person will do once they get there? 

Nothing?

Nothing because I am not sure I follow you.

 he wants to use 1 database for multiple sites i think

It should have said syncing two tables from two different databases...

No what I am saying is you have site 1 http:whatever and a member joins and because the profile table on site 1 and site 2 (http:now.whatever) are identical if you sync those two profile tables the same login can be used on both sites.  Allowing the end user to join the one site and use both sites.  The end user would also be subject to the set of rules setup on both site 1 and site 2.  IOW they could not do everything on site 2 as they can do on site 1 unless you set it up for them to be able to do so.

I think I am correct in this thought process, am I?  The entire Idea is for the person to not have to join both the main site and sub-domain if he/she joins one they join the other...

Lorem Ipsum,
Lorem Ipsum
Lorem Ipsum

The second part of the question is which is easier on the server having two sites like a main domain and a subdomain and the subdomain is dressed down or not having as many cron jobs and fewer modules as the main domain.  In other words if you have 25,000 people online at the same time would the two sites perform better than the single site with all 25,000 on the single site.  The question also was how much does the RMS server affect either one of the 2 configurations.  And Further how would anyone be able to ever calculate what the 25,000 will do when they get there...

You can never calculate what a human will do on a site.

There are some issues that have to be considered.  This could work if you are starting out with a fresh site with no users or if you manually correct both Profiles tables to start at the same index; in other words if you have 30 users on site one and 32 users on site 2 and you want to implement this, then you need to change the index on site one so that you don't get a duplicate index number when someone joins.

To recap what you want, if user joins site 1, then also auto-joins site 2.  If user joins site 2, then is auto-joins to site 1.  User does not get a choice of not joining the other site.  You could just turn off joining on site 2 and have all joins from site 1; you can redirect the join form of site 2 to site 1, if there is no choice of not joining both sites.

I like that but you would still have to sync the profile tables right? Because are you saying that the profile table from site 1 could also drive site 2?  How would that work if that is the case because site 2 will call profile table from site 2?

No, you would simply be placing the profile info on join into the second site as well as the first site; you would open a db connection to the second site database and write to that database's Profiles table.  The person would have to log in to both sites; there would be independent session cookies.  The idea is that they just have to join one time for both sites.