I\'m looking at an existing site and they are using separate databases. The databases seem to be setup in the following manner:
Purely speculation on what was in the minds of the creators:
Maybe a difference in the volitilaty of the data, so that there could be a different backup/replication strategy for the different physical dbs?
Maybe an idea that say, "general types" could be shared across multiple applications but the "site configuration", for example, would be specific to just one application?
Maybe an idea that the different databases could be put on different pieces of hardware that have different performance characteristics, like their RAID configuration. Data that is read a lot but not updated versus data that is updated a lot.
Again, pure speculation...
@Darryl - my answer is more archeology than technology. I'm not saying I buy any of it. I'm just trying to step into the mindset of the ancestors...
If there were a good reason for breaking up a database into a bunch of smaller ones like this, the databases would probably have names like "hadronsupercolliderrawdata" and "googlebackup_2008". Names like "generaltypes" and "memberdata" suggest they were just overwhelmed by stupidity.
I can't think of a reason to create multiple databases for the information you listed, especially if that data needs to be cross-linked. It sounds more like someone didn't know how to use permissions so instead of granting access to tables they just created new databases. Just an opinion, but cutting things down to just one database would probably be an improvement.
Also pure speculation: Perhaps it was an architectural decision to support separation of concerns.
@Corey Trager: Good idea, but you can of course both specify which tables to backup and also, how much difference would it make to only select from some while always updating other tables?