Hello!,

I have two sites that are very similar and would benefit from sharing an accounts table. The two sites, though, have their own databases for their own specific usage but are sub sites of one "umbrella" company

My main questions are:
How is something like this typically organized?
Is it just better to keep everything separate?

I am hoping to be able to keep a database with common account information for the purpose of easier billing, etc.


Thanks for any help guys!

If you (as the developer/designer) can control how the individual "sites" name tables, then there is a good reason to suspect that the sites can share a database. Depending on many external factors, multiple sites sharing one database may or may not be a good idea!

Are these "sites" truly different sites, or just sub-domains of an existing site? Are you hand coding the sites (writing Java, PHP, Perl, etc.), or using a framework (like Drupal, XOOPS, or Joomla)?

There are many answers, but in general it is better to keep the sites "atomic" (completely separate) and then combine the bills. That means that one site can be active while the other is being maintained/migrated/etc. without worry. It adds a step to the billing process, but it is a step that you can probably automate pretty easily.

-PatP

Thanks for reading, Pat

I'm in complete control of every aspect of the build since it's all custom: Server-side code, table schema, etc. The sites would also ideally sit as sub-domains within the umbrella domain. I figure this would be best because although they are different products, they share some design templates and assets and have a similar feel.

You pretty much echoed my main concerns: maintenance and portability. There's something not "correct" in placing all the tables in one database but the idea did cross my mind. it would make it all much easier.

So, assuming I have different databases for each brand(sub-domain) how should I handle login procedure?

This is what i'm thinking:

Three databases
Upon creation of an account, the user table of the corresponding site is updated with a user record allowing that person to login to that particular sub-domain.

Any potential issues with a setup like that?

Thanks again!

I would probably go a couple of steps further in the process that you're following.

I'd make each site completely independant of each other and any admin database. This would make each site "atomic" in the sense that you could move the code and the supporting database as needed. Scale up and scale out are both simple if the sites need to grow. Migration is simple in case you need to either split the load, grow to a bigger server (bandwidth, storage, etc).

At the end of the month, I'd spit out a flat file that represented the billing data from each of the affected sites. Merge those flat files via a simple script, and produce the master billing file. Process the master billing file as you see fit to actually produce the bills that you submit to your client or clients.

This degree of autonomy is critically important to preserve the ability to grow capacity at will. It keeps the managment and the maintenance of each site completely isolated in the sense that the code/data/html/etc forms a complete bundle that does not depend on anything else. Once you have a need to combine information (for billing), you can easily produce the componement pieces (billing files) from each database and send those pieces whereever you need them (the servers can remain completely ignorant of each other). Simply schedule a job to produce the needed files and email them wherever you find appropriate.

Once you get the associated pieces (billing files) whereever you need them, you can process those as you see fit.

Simple pieces, rigorously isolated from each other... Easy to maintain and manage!

-PatP

Pat,

That makes a lot of sense and I'm going to go the route that your suggest.

Thanks for taking your time to explain; it really helps me out!!

Cheers!