Home -> Usenet -> comp.databases.theory -> multiple database dilemma

multiple database dilemma

From: tim erickson <dockersblack_at_hotmail.com>
Date: 19 Aug 2002 17:34:11 -0700
Message-ID: <cfbf4f63.0208191634.27923567_at_posting.google.com> 





Hi,


I'm designing the database of an E-commerce project.
Think of one branch of an organization. I made the design 
and it's like 15 tables. Estimate number of users would be 
around 500. 


(assume only %20 of them access to the system daily 
 and the largest table will have max of 100.000 records and
number of branches are very likely to increase up to 300-400.)



Now the problem is; think of 50 of these branches. Exactly the 
same database structure would be required. My dilemma is;


    
  
  1.   I can add a branchID field inside every table
  
  2.   I can create a seperate DB for each branch.






Let me not forget to mention that the queries are not 
multidatabase queries.



The disadvantage of the first approach is, tables will be overloaded.
One branch would be using only its portion of the table (1/50) where
total table size will be 50 times larger. This will slow down the 
joins and selects. The performance is crucial since its a web application.



My concern with the second approach is, same pages would be 
serving different clients simultaneously, there will be simultanous 
requests from the WEB server which switches between different 
databases. And this might also slow down the performance.



Am I thinking reasonable or is something missing.
Please advice.


Thanks in advance.
Received on Tue Aug 20 2002 - 02:34:11 CEST












Original text of this message