When running a network of sites; which way would you run it?

Run each site on its own database and make members register on each ?
or
Run each site on the same database allowing for members to be a member of all sites?

All thoughts are welcome. This is an open post.

Depends on how user-friendly you want to be. From a user-perspective, its always nice not to have to register multiple times.

You can have a network of 500 sites all with their own database(s) and still have a central login. This said, from my point of view, your question should not be asked that way.

I wish more sites would do a central login. For sites that are very casual it would be awesome.

Some methods are better than others. While I like that Drupal included their auth system where you can do user@site.com and login with the password of your account on site.com, you have to trust the second site won't write down your password.

OpenID seems well thought out and I'm implementing that in a lot of the authentication systems I write. If the user just enters a standard looking username with now /s or .tld then I just look it up in the local user's db. If it looks like a URL I try to do the OpenID system and see if it's valid..

Well, post details on your opinion of how it "should" be done... Just trying to get all types of ideas. I have personally done it several ways but it usually depends on the sites and network.

Just have the registration submit button, insert values into all of your databases at once, Not a smart idea from a security standpoint, but nevertheless.

Just have the registration submit button, insert values into all of your databases at once, Not a smart idea from a security standpoint, but nevertheless.

That's not a security problem, per se. It's a design / maintenance problem :)

I run a bunch of game sites that all use a common framework. The framework is multi-server box and multi-site capable and it all runs from the same core files for every single one of them.

Under my case, I have a universal registration system so if they access any of the sites under the framework, they never have to repeat any data entry.

I guess the real questions are;
Do your sites all utilize the same application code?
Do your site visitors go from site to site from each other?

If you answered no to those, then you should probably keep them in separate databases since they are in fact sites which will probably go in separate development paths down the road.

Otherwise, if they all share a commonality with one another and users from one site use your other sites, then yes, make it as seamless as possible.

I run a bunch of game sites that all use a common framework. The framework is multi-server box and multi-site capable and it all runs from the same core files for every single one of them.

Under my case, I have a universal registration system so if they access any of the sites under the framework, they never have to repeat any data entry.

I guess the real questions are;
Do your sites all utilize the same application code?
Do your site visitors go from site to site from each other?

If you answered no to those, then you should probably keep them in separate databases since they are in fact sites which will probably go in separate development paths down the road.

Otherwise, if they all share a commonality with one another and users from one site use your other sites, then yes, make it as seamless as possible.

You can answer no to both of them and still benifit from a single sign-on architecture. Microsoft Passport capable websites are an example of that.

Check http://www.ja-sig.org/products/cas/ one of the systems that can be used to provide single sign-on functionality.

If the sites are obviously connected (such as one game system per subdomain on the same domain), I would use a central DB. If they're fairly independent sites, my experience has been it causes more confusion than convenience.

It also depends on how often sites come and go. Keeping them separate makes it cleaner to clone and drop sites.