If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > General > Database Concepts & Design > How to deal with more than one site sharing a database?

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old
Registered User
 
Join Date: Jan 2013
Posts: 3
How to deal with more than one site sharing a database?

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!
Reply With Quote
  #2 (permalink)  
Old
Resident Curmudgeon
 
Join Date: Feb 2004
Location: In front of the computer
Posts: 14,421
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
__________________
In theory, theory and practice are identical. In practice, theory and practice are unrelated.
Reply With Quote
  #3 (permalink)  
Old
Registered User
 
Join Date: Jan 2013
Posts: 3
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
PHP Code:
administration_db
   
\_ accounts_tbl
site
-1_db
   
\_ users_tbl
site
-2_db
   
\_ users_tbl 
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!
Reply With Quote
  #4 (permalink)  
Old
Resident Curmudgeon
 
Join Date: Feb 2004
Location: In front of the computer
Posts: 14,421
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
__________________
In theory, theory and practice are identical. In practice, theory and practice are unrelated.
Reply With Quote
  #5 (permalink)  
Old
Registered User
 
Join Date: Jan 2013
Posts: 3
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!
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On