Mohammad wrk wrote:
Hi,
I'm working on a web 2.0 project that targeting small to medium size companies
for providing business services. Companies simply register to the site and then
start their business by loading their data, sharing and discussing them with
others.
The design/architectural decision now we are facing from database perspective
is how we should store companies' specific data? One way is to put all of them
in a single database and partition them by company-id and the other one is to
create, on the fly, a new database per company . The justification for the
latter is that MySQL is not powerful enough (compare to Oracle or DB2) to
handle large amount of data and concurrent users.
I'm new to MySQL and don't know that much about it and this is why I'd like to discuss this concern here.
Funny, I thought you asked the question, should I separate my customers
into their own databases, or use one big DB? Not MySQL sucks, Oracle is
better. :)
Issues I would ask about on this:
1. Is there a chance that given their separation, these DBs will ever
diverge in design because of differences between customers?
2. Could they ever need to be separated for legal reasons? (like one bad
query causing customer data be compromised)
3. Is there any other reason you may do something vastly different from
one customer to another?
If you answer yes to any of these, then you might be best off separating
dbs. But, if you never want to, or expect for any of these things to
happen, you will just be creating headaches for yourself. Backup,
replication, and the need for cross DB queries, will all be a pain in
comparison to a single DB.
I am sure there is more to consider, but these are the points that come
to my mind right away.
Thanks,
Eric
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
